AD-A211  196 


ins  file  con 


/‘V-fS'O/i^o 

Copy  35  of  164  copies 


IDA  PAPER  P-2153 


MANAGEMENT  OF  RISK  AND  UNCERTAINTY  IN 
PRODUCT  DEVELOPMENT  PROCESSES 


Edison  Tse,  Stanford  University 
William  E.  Cralley 


June  1989 


s 


DTIC 

ELECTE  | 
AUG  10 1989  I 


Prepared  for 

Office  of  the  Under  Secretary  of  Defense  for  Acquisition 
(Research  and  Advanced  Technology) 


ID/1 


Approved  for  public  nboN; 
Dtetrlirotkm  Unlimited 


INSTITUTE  FOR  DEFENSE  ANALYSES 

1801  N.  Beauregard  Street,  Alexandria,  Virginia  22311-1772 


89  8  08  047 


IDA  Log  No.  HO  88-33819 


Appro— d  for  public  rdMM:  distribution  unlimrtod. 


SECURITY  CLASSIFICATION  OF  THIS  FAOE 


REPORT  DOCUMENTATION  PAGE 


la.  REFORT  SECURITY  CLASSIFICATION 

UNCLASSIFIED 


2a.  SECURITY  CLASSIFICATION  AUTHORITY 

DD  Form  254  dated  1  October  1983 


2b.  OECLASSIF1CATION/OOWNORADINO  SCHEDULE 

Not  Applicable 


4.  PERFORMING  ORGANIZATION  REFORT  NUMBER(S) 

IDA  Paper  P-2153 


8a.  NAME  OF  PERFORMING  ORGANIZATION 

Institute  for  Defense  Analyses 


6b.  AO  DRESS  (CITY,  STATE,  AND  ZIP  CODE) 

1801  North  Beauregard  Street 
Alexandria,  Virginia  2231 1 


Mb.  RESTRICTIVE  MARKINGS 


1 3.  DISTRIBUTION/ AVAILABILITY  OF  REPORT 


Approved  for  public  release;  distribution  unlimited. 


S.  MONITORING  ORGANIZATION  REPORT  NUMBER  (S) 


6b.  OFFICE  SYMBOL  7a.  NAME  OF  MONITORING  ORGANIZATION 

(n  «*"«*»*•>  OSDi  ouSD(A),  DoD-IDA  Management  Office 


7b.  ADDRESS  (CITY,  STATE.  AND  ZIP  CODE) 

1801  North  Beauregard  Street 
Alexandria,  Virginia  2231 1 


•  a.  NAME  OF  FUNDING/SPONSORINa  ORGANIZATION 

Sb.  OFFICE  SYMBOL 

6.  PROCUREMENT  INSTRUMENT  IDENTIFICATION  NUMBER 

OUSD(A),  R&AT/ET 

MDA  903  89  C  0003 

Be.  ADDRESS  (Ctly,  State,  and  Zip  Code) 

10.  SOURCE  OF  FUNDING  NUMBERS 

The  Pentagon,  Rm.  3D1089 

PROGRAM  ELEMENT 

PROJECT  NO. 

TASK  NO. 

ACCESSION  NO. 
WORK  UNIT 

Washington,  DC  20301-3080 

T-D6-553 

11.  TITLE  (Inoluda  Seourtty  Claaalfloatlon) 

MANAGEMENT  OF  RISK  AND  UNCERTAINTY  IN  PRODUCT  DEVELOPMENT  PROCESSES 


12.  PERSONAL  AUTHOR(S). 


13.  TYPE  OP  REPORT 

Final 


IS.  SUPPLEMENTARY  NOTATION 


Edison  Tse,  Stanford  University,  and  William  E.  Cralley 


13b.  TIME  COVERED 

14.  DATE  OF  REPORT  (Year,  Month,  Day) 

FROM  TO 

4/88  9/88 

Juno  1989 

IS.  PAQE  COUNT 

95 


sub-oroup  |  Concurrent  Engineering,  Simultaneous  Engineering,  Engineering  Management,  Risk, 
Uncertainty,  Overlapping  Development  Process,  Quality,  Life  Cycle  Cost,  Unified 
Lite  Cycle  Engineering,  Taguchi  Methods,  Loss  Function,  Decision  Support  Systems 


16.  ABSTRACT  (Coni In ua  on  ravaraa  V  naoaaaarv  and  Idantlfv  bv  block  number! 

The  goal  of  the  Unified  Life  Cycle  Engineering  (ULCE)  program  is  to  develop  enhanced  design  environments  that  will  allow 
supportability  and  producibility  to  be  considered  early  in  the  product  design  cycle  along  with  the  usual  factors  of  cost,  per¬ 
formance,  and  schedule.  This  paper  considers  the  engineering  management  aspects  of  one  approach  to  ULCE:  an  overlapping 
development  process  in  which  technology  development,  design,  manufacturing  process  planning,  and  support  process  planning 
are  conducted  In  parallel.  Such  a  process,  commonly  called  concurrent  engineering,  has  shown  considerable  promise  in  com¬ 
mercial  industry  in  reducing  development  lead  time,  reducing  product  cost,  and  improving  quality.  However,  such  a  process 
also  requires  much  more  careful  management  due  to  the  increased  risk  and  uncertainties  which  result  from  the  incomplete 
information  transfers  which  must  of  necessity  occur  between  the  learns  performing  the  different  phases  of  the  development 
This  paper  presents  an  analytical  approach  to  management  of  overlapping  development  processes  in  the  lace  of  such  risks 
and  uncertainties.  The  approach  taken  is  similar  to  that  of  Taguchi  in  that  a  key  aspect  of  the  method  is  the  development  ot 
a  loss  function  which  is  used  to  gauge  the  relative  undesirability  of  various  courses  of  action  in  the  development  process. 


20.  DISTRIBUTION/ AVAILABILITY  OP  ABSTRACT 
□  UNCLASSIFIED/ UNLIMITED  (£]  SAME  AS  REPORT  Q  OTIC  USERS 

21.  ABSTRACT  SECURITY  CLASSIFICATION 

UNCLASSIFIED 

22a.  NAME  OP  RESPONSIBLE  INDIVIDUAL 

22b.  TELEPHONE  (Inelud#  Area  Code) 

22C.  OFFICE 
SYMBOL 

DO  FORM  1473.  44  MAR 


C  S.  6-16-89 


UNCLASSIFIED 


SECURITY  CLASSIFICATION  OF  THIS  PAQE 


IDA  PAPER  P-2153 


MANAGEMENT  OF  RISK  AND  UNCERTAINTY  IN 
PRODUCT  DEVELOPMENT  PROCESSES 


Edison  Tse,  Stanford  University 
William  E.  Cralley 


June  1989 


ID/I 


INSTITUTE  FOR  DEFENSE  ANALYSES 


Contract  MDA  903  89  C  0003 


PREFACE 


This  report  was  prepared  by  the  Institute  for  Defense  Analyses  (IDA)  for  the  Office 
of  Engineering  Technology,  Deputy  Under  Secretary  of  Defense  (Research  and  Advanced 
Technology),  and  the  Air  Force  Human  Resources  Laboratory  under  Contract  Number 
MDA  803  89  C  0003,  Task  Order  T-D6-553,  "Applications  of  Systems  Engineering 
Techniques  to  Development  of  an  Unified  Life  Cycle  Engineering  Environment." 

The  issuance  of  this  report  satisfies  subtask  (4):  "Investigate  methods  of 
structuring  a  design  process  which  will  allow  for  a  measure  of  robustness  in  that  process  in 
the  face  of  uncertain  change  in  design  requirements  or  unforeseen  circumstances  arising  in 
the  course  of  the  design." 

This  paper  was  reviewed  by  Drs.  Frederick  R.  Riddell  and  James  Pennell  of  IDA 
and  by  Professor  Daniel  P.  Schrage  of  the  Georgia  Institute  of  Technology,  a  consultant  to 
IDA. 


m 


Accession  For 

/ 

NTIS  GRA&I 

w 

DTIC  TAB 

□ 

Unannounced 
Justification _ 

□ 

By 

Distribution/ 


Availability  Codes 
Avail  and/or 
Dist  |  Special 


\ 


CONTENTS 


PREFACE . iii 

EXECUTIVE  SUMMARY . ES- 1 

A.  Background . ES-1 

B .  Uncertainty  and  Risk  in  Product  Development . ES- 1 

C.  Approach  to  Handling  Uncertainties . ES-2 

D.  Management  Issues . ES-3 

E.  Conclusions  and  Recommendations . ES-3 

1.  Evaluation  of  the  Generalized  Loss  Function . ES-4 

2 .  Assessment  of  Requirements  Ambiguity  Based  on  Perceived  Need....  ES-5 

3 .  Design  Concept  Evaluation-Integrating  Requirements  Ambiguity 

and  the  Generalized  Loss  Function . ES-5 

4.  Managing  the  Dynamic  Reduction  of  Upstream  Ambiguity . ES-5 

5 .  Demonstration  of  Applicability  of  the  Methodology  to  Specific 

Classes  of  Problems  via  Real  Cases . ES-6 

6 .  ULCE  Decision  Support  Environment . ES-6 

I.  INTRODUCTION . 1-1 

A.  Background . 1-1 

B .  Approaches  to  Unified  Life  Cycle  Engineering . I- 1 

C.  Management  of  Risk  and  Uncertainty . 1-2 

D.  Organization  of  the  Report . 1-3 

II.  PRODUCT  DEVELOPMENT  PROCESSES . Il  l 

A.  Introduction . II- 1 

B.  Characterization  of  Product  Development  Processes . II-2 

C .  Alternative  Product  Development  Processes . II-4 

1.  Serial  Approach . II-5 

2.  Overlapping  Approach . II-6 

D.  Management  Issues . II-9 


III.  BASIC  CONCEPTS  OF  RISK  AND  RISK  EVALUATION . III-l 

A.  Types  of  Risk . Ill- 1 

B .  Risk  Management  for  Two-Stage  Processes . III-2 

C.  Application  to  the  Three  Categories  of  Risk . ni-5 

1 .  Uncertainty  in  Requirements . III-5 

2.  Uncertainty  in  Parts  Availability . III-7 

3 .  Uncertainty  in  New  Technology . III-9 

D.  General  Remarks . Ill- 11 

IV.  INTEGRATION  OF  UPSTREAM  AND  DOWNSTREAM 

UNCERTAINTIES . IV- 1 

A.  Three-Phase  Processes . IV- 1 

1 .  Upstream  Phase  and  Design  Phase . IV- 1 

2.  Downstream  Phase . IV-2 

3 .  Integration  of  Phases . IV-3 

B.  Parameter  Optimization . IV-3 

1 .  General  Product  Development  System  Model . IV-4 

2.  Response  Function . IV-5 

3 .  Mathematical  Formulation  of  Parameter  Optimization  Problem . IV-6 

4.  Computational  Issues . IV-9 

5 .  Developing  the  Quality  Versus  LCC  Trade-Off  Curve . IV- 10 

C .  Management  of  Uncertainties . IV- 1 1 

1 .  Management  of  Upstream  Requirements  Uncertainties . IV- 1 1 

2.  Selection  of  Design  Concept . IV- 13 

3 .  Dynamic  Reduction  of  Requirements  Uncertainties . IV-13 

4.  Flexible  Design . IV-15 

5 .  Staging  of  Development  Phases  in  Product  Development . IV- 1 6 

D.  Applications  to  Managing  Upstream  Uncertainty . IV- 19 

1 .  Concurrent  Engineering . IV- 1 9 

2 .  Planning  of  a  Science  and  Technology  Program  in 

Conjunction  with  Advanced  System  Developments . IV-20 

E .  Application  to  Management  of  Downstream  Uncertainties . IV-2 1 

1 .  Downstream  Uncertainties  and  Reliability  Specification . IV-21 

2.  Uncertainty  in  Reliability  and  Parts  Availability . IV-24 

V.  DECISION  SUPPORT  SYSTEM  REQUIREMENTS . V-l 

A.  Management  Structure  to  Support  Overlapping  Process . V-l 

B .  Decision  Support  Systems  for  Uncertainty  Management . V-2 


vi 


VI.  SUMMARY  AND  RECOMMENDATIONS . VI- 1 

A.  Summary . VI-1 

B .  Recommendations  for  Further  Research  and  Development . VI-2 

1.  Evaluation  of  the  Generalized  Loss  Function . VI-2 

2.  Assessment  of  Requirements  Ambiguity  Based  on  Perceived  Need.....VI-3 

3 .  Design  Concept  Evaluation— Integrating  Requirements  Ambiguity 

and  Ae  Generalized  Loss  Function  Approach  for  Downstream 
Uncertainty . VI-3 

4.  Managing  the  Dynamic  Reduction  of  Upstream  Ambiguity . VI-3 

5 .  Demonstration  of  Applicability  of  the  Methodology  to  Specific 

Classes  of  Problems  via  Real  Cases . VI-5 

6 .  ULCE  Decision  Support  Environment . VI-5 

REFERENCES . R-l 


vii 


FIGURES 


II- 1 .  Frontier  Curve . II-4 

II-2.  Serial  Approach . II-5 

II- 3.  Overlapping  Approach . II-7 

II-4.  Activity  Profile  Within  a  Phase  Duration . II- 8 

II- 5.  Funnel  Process . II-9 

m-i.  Plots  of  fi(e) . rri-4 

III- 2.  Plots  of  f.  vs.  as  Uncertainty  Changes . III-5 

III- 3.  Handling  of  Uncertainty  in  Requirements . HI-6 

HI-4.  Total  Life  Cycle  Cost  as  a  Function  of  Parts  Availability . HI- 8 

ni-5 .  Cost  as  a  Function  of  the  Time  When  New  Technology  is  Available . Ill- 1 0 

ni-6.  Variation  of  Figure  HI-5  When  Ti  >  T2 . Ill- 1 1 

IV-  1 .  Interactions  Among  Phases  in  a  Development  Process . IV- 1 

IV-2.  Development  Process  System  Model . IV-4 

IV-3.  Dependence  of  Minimum  Life  Cycle  Cost  on  Allowable  Quality . IV-8 

IV-4.  Upstream-Downstream  Interactions . IV-12 

IV-5.  Modifications  in  7t'(eu)  for  Unconflicting  Situations . IV-12 

IV-6.  Comparison  of  Three  Basic  Design  Approaches . IV- 14 

IV-7.  Market-Driven  Process . IV-18 

IV-8.  Technology-Driven  Process . IV-18 

IV-9.  Mixed  Process . IV-18 

IV-10.  Complex  Mixed  Process . IV-19 


IV- 1 1 .  Cost  Components  of  LCC . IV-23 

IV- 1 2.  The  LCC  Curve . IV-23 

IV-13.  LCCs  Curve  as  Compared  to  LCC  Curve . IV-25 

IV-14.  System  Life  Cycle  Cost  as  a  Function  of  i . IV-26 

V- 1 .  Management  Structure  for  Overlapping  Paradigm . V-2 

V-2.  ULCE  Environment . V-5 


x 


EXECUTIVE  SUMMARY 


A.  BACKGROUND 

Unified  Life  Cycle  Engineering  (ULCE)  is  an  Air  Force  Project  Forecast  II  R&D 
Initiative  whose  goal  is  development  of: 

A  design  engineering  environment  in  which  computer-aided  design  technology 
is  used  to  continually  assess  and  improve  the  quality  of  a  product  during  the 
active  design  phases  as  well  as  throughout  its  entire  life  cycle  by  integrating  and 
optimizing  design  attributes  for  produc  Ability  and  supportability  with  design 
attributes  for  performance,  cost,  and  schedule.  [Ref.  1] 

In  1986,  IDA  was  requested  to  analyze  the  requirements  for  decision  support  to 
support  an  ULCE  design  process.  The  results  of  that  analysis  indicated  that  planning  and 
management  of  the  design  process  (meta-design)  are  key  factors  in  successfully 
implementing  ULCE.  This  report  contains  the  results  of  a  follow-on  effort  to  IDA's  initial 
work  on  architecture  and  integration  requirements  for  ULCE  in  which  we  address  the 
problem  of  uncertainty  in  product  development- how  to  quantify  it,  manage  it,  and  make 
good  design  decisions  in  its  presence. 

B ,  UNCERTAINTY  AND  RISK  IN  PRODUCT  DEVELOPMENT 

Uncertainties  come  in  various  forms  in  product  development.  The  design  team 
faces  both  upstream  and  downstream  uncertainties.  Upstream  uncertainties  include,  for 
example,  uncertainty  in  the  specification  of  design  requirements.  This  uncertainty  reUtes  to 
the  possibility  of  modification  of  the  original  specification  that  they  are  designing  to.  Such 
changes  occur  frequently  in  weapon  systems  procurements  and  can  cause  havoc  in  the 
design  process.  Downstream  uncertainties  may  reflect  a  lack  of  knowledge  as  to  the 
environment  in  which  the  product  will  be  used  or  uncertainties  in  future  availability  of  spare 
parts.  Uncertainties  in  manufacturing  processes,  such  as  process  variability,  are  also 
examples  of  downstream  uncertainties  from  a  design  standpoint 
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Another  class  of  uncertainties  pertains  to  processes  in  which  there  are  parallel 
efforts  being  conducted  that  must  come  together  at  some  point  to  develop  the  total  product. 
One  example  of  this  is  when  both  a  design  and  an  R&D  activity  are  being  pursued  in 
parallel,  with  the  design  team  assuming  that  the  R&D  activity  will  be  able  to  develop  a  new 
technology  needed  by  the  designers  at  a  certain  time.  The  designers  should  consider  that 
the  actual  time  of  availability  of  the  new  technology  is  uncertain,  and  should  structure  their 
activities  accordingly.  Entire  design  approaches  have  been  scrapped  after  much  work 
because  a  critical  technology  did  not  materialize  when  it  was  needed  and  the  designers  had 
not  taken  the  uncertainly  of  the  technology’s  availability  into  account 

Clearly,  if  we  are  to  consider  uncertainties  in  the  product  development  process,  we 
need  a  structured  approach  in  which  to  do  this.  In  this  report,  one  such  approach  for 
management  of  uncertainty  is  presented.  This  approach  is  based  on  the  paradigm  of  a  loss 
function  that  is  similar  to  that  of  Taguchi's  parameter  optimization  methodology.  [Ref.  4] 

C.  APPROACH  TO  HANDLING  UNCERTAINTIES 

The  Taguchi  method  of  parameter  design  is  a  method  for  determining  a  set  of 
design  parameters  that  make  the  resulting  design  robust  in  the  sense  that  its  expected 
deviation  (in  the  face  of  internal  and  external  noise)  from  a  set  of  target  specifications,  as 
measured  by  a  loss  function,  is  minimized.  The  Taguchi  method  is  thus  a  design 
methodology  structured  toward  handling  of  downstream  uncertainties.  In  this  paper  we 
propose  an  approach  that  allows  the  product  development  team  to  address  not  only 
downstream  but  also  upstream  uncertainties  and  to  balance  the  reduction  of  both  types  of 
uncertainty  against  the  achievement  of  a  low  product  life  cycle  cost. 

This  is  accomplished  through  the  development  of  a  generalized  loss  function  that 
incorporates  not  only  variability  but  also  life  cycle  cost.  Once  such  a  generalized  loss 
function  has  been  computed,  it  can  be  used  to  evaluate  alternative  design  concepts  from  the 
standpoint  of  their  robustness  to  deviations  in  requirements  (i.e.,  upstream  uncertainty). 
An  approach,  based  on  trading  off  expected  loss  versus  risk  of  loss  (variability  of  loss 
based  on  the  upstream  uncertainty  distribution)  has  been  developed,  which  allows 
evaluation  of  alternative  design  concepts  and  also  provides  guidance  for  altering  the 
requirements  in  cases  where  such  alterations  may  greatly  reduce  expected  loss. 

A  design  concept  that  is  robust  with  respect  to  the  design  requirements  is  called  a 
flexible  design  concept.  Within  such  a  concept,  we  can  vary  individual  details  in  such  a 


way  as  to  satisfy  a  variety  of  requirements.  Without  such  flexibility,  a  change  in 
requirements  may  necessitate  going  to  a  completely  new  design  concept,  with  subsequent 
loss  of  a  great  deal  of  engineering  manhours  that  have  been  expended  on  the  old  concept. 
Flexible  design  concepts  thus  offer  lower  risk  in  terms  of  increased  robustness  to  changes 
in  requirements.  However,  such  a  flexible  concept  may  achieve  a  lower  level  of 
performance  than  more  restrictive  concepts.  Thus  a  trade-off  must  be  made  based  on  one’s 
relative  preference  for  high  performance  versus  low  risk. 

D.  MANAGEMENT  ISSUES 

While  uncertainties  should  be  considered  to  some  extent  in  all  product  development 
processes,  processes  in  which  there  is  a  considerable  degree  of  overlap  in  different  phases, 
such  as  the  concurrent  design  or  simultaneous  engineering  approaches,  require  special 
attention  by  management  to  control  of  uncertainty  and  risk.  This  increased  demand  for 
management  control  arises  from  the  greater  uncertainties  faced  by  members  within  each 
phase--the  members  have  to  deal  with  a  large  degree  of  ambiguity  in  their  problem  solving 
activities  at  the  beginning.  However,  as  time  progresses,  the  ambiguity  starts  to  decrease. 
When  much  ambiguity  exists,  the  team  members  need  to  factor  flexibility  concepts  into 
their  activities,  such  as  investigating  alternative  paths  and  building  in  buffers  to  allow  for 
change.  When  the  ambiguity  has  been  reduced  to  some  threshold  level,  the  problem 
solving  activities  can  then  focus  on  considerations  of  optimization. 

Such  a  problem  solving  process  is  analogous  to  the  funnel  process  [Ref.  2],  except 
in  this  case,  we  are  dealing  with  the  development  of  a  specific  product,  rather  than  the 
selection  of  new  ideas  or  innovations  to  be  further  developed  and  marketed.  In  the  case  of 
a  design  project,  the  degree  of  flexibility  to  be  introduced  in  the  beginning  of  the  funnel 
process  is  directly  proportional  to  the  level  of  ambiguity  the  team  members  have  to  face  in 
the  beginning  of  the  phase  and  inversely  proportional  to  the  cost  of  introducing  such 
flexibility.  A  major  management  issue  arises  in  controlling  the  shape  of  the  funnel-the 
dynamic  reduction  in  ambiguity  over  time. 

E.  CONCLUSIONS  AND  RECOMMENDATIONS 

It  should  be  emphar  ed  that  the  research  reported  here  is  focused  at  providing  a 
foundation  that  allows  r;,  :  address  ULCE  properly  from  a  risk  perspective.  Given 
competitive  pressures,  looming  how  to  develop  products  using  the  most  recent  technology 
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in  a  timely  manner  to  meet  user  needs,  while  keeping  life  cycle  cost  low  is  becoming 
increasingly  important  This  demands  far  more  control  in  risk  management  throughout  the 
process.  Unfortunately,  this  issue  has  been  rarely  addressed  in  the  vast  array  of  research 
activities  focused  on  product  design  and  manufacturing. 

Our  contribution  is  a  broad  treatment  of  such  issues  and  development  of  a 
foundation  for  further  research  activities.  However,  this  report  only  provides  a  solution 
method  at  a  conceptual  level.  To  further  develop  the  method  into  a  practical  tool,  we  must 
describe  how  to  develop  the  response  model,  the  model  for  the  downstream  uncertainties, 
and  the  optimization  methods  which  will  be  required.  In  practice,  the  construction  of  such 
models  is  the  major  difficulty.  In  many  cases,  analytical  form  for  such  models  may  not  be 
obtainable,  which  prohibits  straightforward  application  of  standard  optimization  methods. 

Another  difficulty  lies  in  the  assessment  of  uncertainties  in  deriving  the  loss 
function.  Such  assessment  may  be  done  by  extracting  experts'  opinions  in  common 
situations  or  via  a  Monte  Carlo  simulation  method.  Different  types  of  difficulties  are 
associated  with  these  two  approaches— the  first  approach  requires  facing  the  issue  of 
converting  expert  knowledge  into  an  appropriate  distribution;  the  second  problem  requires 
facing  the  issue  of  choosing  the  right  level  of  model  aggregation  with  an  appropriate  model 
error  representation. 

Recommendations  for  specific  research  areas  that  need  attention  are  described  in  the 
following  paragraphs. 

1.  Evaluation  of  the  Generalized  Loss  Function 

In  this  research,  we  have  developed  the  concept  of  the  generalized  loss  function, 
which  balances  life  cycle  cost  with  quality  lost  due  to  deviation  from  target  values 
(variability).  Such  a  function  would  play  a  major  role  in  the  whole  risk  management 
process.  Thus  the  success  or  failure  of  implementing  the  method  discussed  in  this  paper 
hinges  on  being  able  to  derive  or  approximate  this  function.  This  computation  involves 
solving  two  optimization  problems,  as  outlined  in  Chapter  IV.  Research  on  a  methodology 
to  solve  these  optimization  problems,  which  in  many  situations  cannot  be  represented  in 
analytical  form,  is  needed. 
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2.  Assessment  of  Requirements  Ambiguity  Based  on  Perceived  Need 

The  next  critical  function  that  is  needed  to  perform  risk  management  is 
quantification  of  requirements  ambiguity.  This  function  is  assessed  in  the  beginning  of  the 
design  process  based  on  some  unclear  notions  of  how  the  product  should  be  used.  Note 
that  this  is  not  a  statistical  uncertainty  but  rather  a  reflection  of  the  limits  of  our  knowledge 
of  how  achieving  certain  requirements  will  meet  the  user’s  needs. 

3 .  Design  Concept  Evaluation-Integrating  Requirements  Ambiguity  and 
the  Generalized  Loss  Function 

While  integrating  requirements  ambiguity  and  the  generalized  loss  function  is, 
conceptually,  rather  straightforward  (as  described  in  Chapter  IV),  practical  implementation 
is  difficult.  Note  that  the  integration  hinges  on  generating  the  requirements  uncertainty 
distribution  as  well  as  the  generalized  loss  function.  When  the  input  requirements  space  is 
a  continuous  parameter  set,  the  generation  of  these  two  functions  for  all  parameters  will  be 
totally  impractical.  We  need  a  methodology  to  allow  us  to  approximately  evaluate  design 
concepts  without  requiring  us  to  evaluate  requirements  uncertainty  and  the  loss  function 
over  such  a  continuous  parameter  set 

4.  Managing  the  Dynamic  Reduction  of  Upstream  Ambiguity 

One  cycle  of  the  downstream  and  upstream  integration  will  result  in  either  a 
reduction  of  requirements  ambiguity  or  identification  of  a  potential  conflict  situation.  The 
management  issues  are  how  to  further  reduce  the  requirements  ambiguity  in  the  first 
situation  and  how  to  resolve  conflict  when  the  second  situation  arises.  The  solution  for 
both  management  issues  hinges  on  exploring  the  effective  use  of  resources  to  carry  out 
certain  activities  that  will  modify  or  refine  the  assessments  of  requirements  uncertainty  and 
the  generalized  loss  function. 

The  manager  must  choose  from  a  host  of  options  to  continue  the  reduction  of 
requirements  uncertainties  in  some  optimum  manner  or  try  to  resolve  potential  conflicts. 
Each  of  these  activities  requires  resources  of  dollars,  man-hours,  and  time.  Thus  the 
problem  is  one  of  resource  allocation  so  that 

«  The  project  can  be  finished  "on  time," 

•  The  development  cost  is  within  budget,  and 

•  The  available  resources  are  optimally  used. 


This  resource  allocation  problem  is  non-standard  since  all  possible  options  are  not  specified 
a  priori.  Rather,  the  generation  of  new  options  may  result  from  an  assessment  of  the 
solution  of  an  old  resource  allocation  problem  and  exploring  how  combinations  of  certain 
activities  will  influence  the  requirements  uncertainty  and  loss  function. 

5 .  Demonstration  of  Applicability  of  the  Methodology  to  Specific  Classes 
of  Problems  via  Real  Cases 

Since  the  development  process  and  the  method  proposed  in  this  paper  are  different 
from  conventional  practice,  before  one  can  develop  some  of  the  heuristics  discussed  in  this 
paper,  one  needs  to  accumulate  working  experiences  by  applying  the  methodology  to 
specific  classes  of  product  development  problems.  Another  objective  of  such  application  is 
to  demonstrate  the  usefulness  of  the  methodology.  We  propose  that  real  application  cases, 
which  by  themselves  are  topics  of  significant  importance,  be  considered  for  evaluation  of 
this  methodology. 

Some  of  these  potential  application  areas  include  managing  the  contracting  process, 
product  identification  and  development,  concurrent  engineering  in  high  technology  product 
development,  and  planning  of  a  Science  and  Technology  (S&T)  Program  in  conjunction 
with  advanced  weapon  system  development. 

6.  ULCE  Decision  Support  Environment 

To  support  the  ULCE  implementation  process,  we  need  to  develop  an  ULCE 
environment  that  can  support  the  manager  in  controlling  dynamic  reduction  in  requirements 
ambiguity  and  the  functional  groups  in  integrating  the  downstream  and  upstream  analysis 
process  when  a  specific  ambiguity  level  is  provided  by  the  manager.  Individual  decision 
support  systems  are  currently  being  developed  for  supporting  certain  specific  functional 
group  activities  [e.g.,  computer-aided  design  (CAD)/computer-aided  manufacturing 
(CAM)].  It  is  impractical  to  ignore  all  the  existing  systems  and  redevelop  a  new  ULCE 
environment  from  scratch.  Therefore,  research  on  how  to  integrate  and  evolve  the  current 
systems  to  the  target  ULCE  environment  is  the  major  challenge.  We  believe  that  this 
requires,  first,  a  thorough  understanding  of  the  workings  of  the  overlapping  process  as 
well  as  how  the  management  issues  arising  from  such  processes  can  be  addressed  and 
solved  effectively  before  the  proper  ULCE  decision  support  environment  can  be  designed. 
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I.  INTRODUCTION 


A.  BACKGROUND 

Unified  Life  Cycle  Engineering  (ULCE)  is  an  Air  Force  Project  Forecast  II  R&D 
Initiative  whose  goal  is  development  of 

A  design  engineering  environment  in  which  computer-aided  design  technology 
is  used  to  continually  assess  and  improve  the  quality  of  a  product  during  the 
active  design  phases  as  well  as  throughout  its  entire  life  cycle  by  integrating  and 
optimizing  design  attributes  for  producibility  and  supportability  with  design 
attributes  for  performance,  cost,  and  schedule.  [Ref.  1] 

In  view  of  the  recognition  that  design  decisionmaking  is  a  key  element  of  any 
successful  approach  to  ULCE,  the  Air  Force  in  1986  requested  that  the  Institute  for 
Defense  Analyses  (IDA)  identify  requirements  and  issues  related  to  design  decision  support 
that  should  be  addressed  by  the  Air  Force  through  additional  research  and  development 
activities.  In  response,  EDA  formed  a  working  group  of  individuals  from  industry, 
academia,  and  government  to  address  this  question.  This  working  group  recommended, 
among  other  things,  that  applications  of  systems  engineering  techniques  and  tools  be 
considered  in  the  structuring  of  ULCE  itself.  The  design  and  development  process  is  itself 
a  system  whose  inputs  are  perceived  user  needs  and  whose  output  is  a  weapon  system 
designed  to  meet  those  needs.  As  a  follow-on  to  this  recommendation,  the  Air  Force 
requested  that  IDA  conduct  a  study  of  systems  engineering  methodologies,  identifying 
various  ways  that  such  methodologies  could  be  applied  to  ULCE  development  This  report 
constitutes  a  portion  of  IDA's  response  to  this  request. 

B .  APPROACHES  TO  UNIFIED  LIFE  CYCLE  ENGINEERING 

The  primary  focus  of  the  ULCE  program  has  been  on  applications  of  computer- 
aided  design  (CAD)  technology  to  improve  the  way  weapons  are  designed.  In  particular, 
the  Air  Force  RAMCAD  (reliability,  availability,  and  maintainability  through  computer- 
aided  design)  development  program,  which  is  one  of  the  ULCE  core  programs,  seeks  to 


integrate  reliability,  maintainability,  and  supportability  (R,M&S)  analysis  tools  with  a  CAD 
system  to  facilitate  rapid  analysis  and  turnaround  in  evaluation  of  designs  from  an  RJvf&S 
viewpoint.  Such  capabilities  will  allow  designs  to  be  influenced  from  an  R,M&S 
standpoint  during  the  active  design  phase,  when  there  is  still  enough  flexibility  to  allow  for 
changes.  This  is  a  simple  example  of  how  designs  can  be  improved  by  making  information 
about  the  effect  of  the  designer’s  decisions  on  some  downstream  characteristic  available  to 
the  designer  during  design  creation. 

The  logical  extension  of  the  RAMCAD  approach  leads  to  development  of  intelligent 
CAD  systems  linked  to  knowledge-based  systems  with  the  ability  to  reason  through  the 
implications  of  each  design  decision  with  regard  to  all  downstream  factors  such  as 
manufacturability,  cost,  safety,  reliability,  and  maintainability  and  to  return  advice  and 
information  to  the  designer  on  not  only  the  implications  of  his  decision  but  also  alternative 
courses  of  action  that  might  be  considered.  This  approach  appears  to  be  feasible  as  long  as 
we  are  working  in  an  area  where  the  number  of  alternative  decisions  and  possible 
implications  of  such  decisions  are  small  enough  to  make  development  of  a  rule  base 
feasible. 

As  we  move  to  higher  levels  of  complexity  in  a  modem  weapon  system,  however, 
detailed  tracking  of  all  the  possible  implications  of  each  decision  throughout  the  hierarchy 
and  through  all  of  the  downstream  processes  quickly  becomes  very  difficult.  It  is  at  this 
point  that  we  must  begin  to  take  a  systems  view  of  the  design  process  and  recognize  that 
decisions  must  be  made  without  complete  information  on  all  of  their  implications. 
Moreover,  the  inputs  upon  which  decisions  are  made  are  also  subject  to  change  as  we 
proceed  through  the  design  process.  Thus  if  we  are  to  develop  an  ULCE  system  that 
handles  the  total  design  process  for  a  complex  weapon  system,  we  must  address  issues  of 
management  of  the  design  process  in  the  face  of  uncertainties  of  various  sorts. 

C.  MANAGEMENT  OF  RISK  AND  UNCERTAINTY 

Risk  and  uncertainty  enter  the  development  process  from  a  variety  of  sources.  At 
the  beginning  of  the  process,  a  set  of  requirements  and  specifications  for  the  product  to  be 
developed  must  be  supplied  to  the  design  team.  During  the  course  of  the  design  effort, 
changes  in  these  specifications  are  often  necessary.  Such  changes  can  result  in  redesign 
efforts,  the  cost  of  which  increases  exponentially  as  they  are  undertaken  later  and  later  in 
the  development  process. 


In  the  case  of  modern  weapon  systems,  in  which  state-of-the-art  performance  is 
required,  we.  also  have  significant  technological  risks  to  contend  with.  To  meet  the 
performance  requirements,  a  new  technology  may  be  required.  There  will  be  uncertainty 
about  whether  such  technology  is  possible,  and,  if  possible,  when  it  will  be  available. 
Delays  in  availability  of  particular  technologies  may  lead  to  schedule  slippage  and  cost 
overruns  when  alternative  design  concepts  must  be  adopted  in  the  absence  of  the  required 
technology. 

Risks  and  uncertainties  also  arise  from  downstream  considerations.  There  may  be 
considerable  uncertainty  regarding  the  ability  of  available  manufacturing  processes  to 
produce  the  design  within  acceptable  tolerances.  There  may  also  be  uncertainties  regarding 
the  usage  environment  for  the  weapon  system  once  it  is  deployed.  Other  uncertainties 
include  such  things  as  parts  availability  and  the  availability  of  sufficiently  skilled  personnel 
to  operate  and  maintain  the  system  when  it  is  finally  deployed. 

Management  and  structuring  of  the  development  process  in  such  a  way  as  to 
properly  cope  with  these  risks  and  uncertainties  is  a  key  issue  for  ULCE.  In  this  report, 
we  examine  some  of  the  management  problems  inherent  in  various  approaches  to  product 
development  and  offer  an  overall  structure  for  attacking  these  problems.  It  is  our  view  that 
the  presence  of  uncertainties  and  risk  must  be  openly  acknowledged  and  explicitly  dealt 
with  in  structuring  and  managing  the  product  development  process.  Many  current  practices 
in  design,  for  example,  ignore  the  presence  of  uncertainties  from  both  upstream  and 
downstream  sources.  Such  a  practice  contributes  significantly  to  failure  to  meet  schedule 
constraints  and  increased  development  costs. 

D.  ORGANIZATION  OF  THE  REPORT 

This  report  contains  a  conceptual  approach  to  management  of  risk  and  uncertainties 
in  product  development  and  illustrates  this  approach  in  various  sample  application 
examples. 

In  Chapter  II,  we  examine  alternative  ways  product  development  processes  can  be 
structured.  In  particular  we  contrast  the  serial  approach  with  an  overlapping  approach, 
which  is  becoming  popular  with  the  adoption  of  concurrent  design  processes.  We  also 
identify  issues  related  to  the  management  of  these  processes. 


In  Chapter  ID,  we  consider  a  simple  paradigm  for  managing  uncertainties  in  a 
situation  with  two  phases  of  a  development.  This  case  is  simplified  to  allow  the  reader  to 
grasp  the  essentials  of  our  approach  without  being  overwhelmed  by  excessive  detail. 

In  Chapter  IV,  we  consider  the  more  complicated  case  of  management  of 
uncertainty  from  multiple  sources.  In  particular,  we  consider  the  management,  from  a 
design  standpoint,  of  both  downstream  uncertainties  and  upstream  uncertainties.  We  have 
developed  an  approach  that  allows  for  designs  to  be  optimized  for  not  only  minimal 
expected  loss  due  to  internal  and  external  noises  (as  in  the  Taguchi  approach  [Ref.  4]),  but 
also  acceptable  life  cycle  cost  We  conclude  this  chapter  with  several  example  formulations 
of  the  approach  for  specific  problems. 

In  Chapter  V,  we  address  the  issue  of  decision  support  requirements  for 
management  of  uncertainty  and  risk  in  product  development.  An  architecture  is  presented 
for  a  hierarchically  linked  set  of  workstations  for  both  management  of  the  process  and 
design  and  other  technically  oriented  work  by  the  development  team  members. 

Finally,  in  Chapter  VI,  we  summarize  the  results  of  this  report  and  present 
conclusions  and  recommendations  for  future  research. 
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n.  PRODUCT  DEVELOPMENT  PROCESSES 


A.  INTRODUCTION 

Product  development  is  a  risky  proposition.  In  the  beginning,  the  process  is 
triggered  by  user  needs  and  requirements,  some  of  which  may  be  rather  vaguely  stated.  To 
see  whether  such  needs  can  be  fulfilled,  we  must  have  some  expectation  of  what  is 
technically  feasible-what  the  realm  of  possibility  is.  The  process  of  combining  these  needs 
and  possibilities  will  result  in  a  more  concrete  specification  of  functional  requirements  for 
the  product.  The  design  process  is  a  problem  solving  process  in  which  creativity  and 
knowledge  are  applied  to  the  construction  of  a  physical  object  that  satisfies  such  a 
functional  requirements  specification.  Product  development  does  not  begin  with  design  but 
actually  starts  with  determination  of  needs  and  the  development  of  functional  specifications 
that  we  expect  to  be  achievable  with  available  technology.  The  total  process,  beginning 
with  user  needs  and  specification  of  functional  requirements  and  through  actual  delivery  of 
the  first  unit  of  the  product  to  the  customer,  is  referred  to  as  the  product  development 
process. 

The  product  development  process  is  anything  but  deterministic.  However,  the 
conventional  approach  to  product  development  takes  little  account  of  the  uncertainties 
inherent  in  the  problem.  Determination  of  functional  requirements,  design,  and 
manufacturing  are  treated  as  three  disjointed  subprocesses  with  output  of  one  process 
serving  as  a  deterministic  input  to  the  next  process.  Within  each  subprocess,  stochastic 
variations,  which  are  statistical  in  nature,  are  considered  by  methods  such  as  statistical 
process  control.  The  management  of  uncertainties  between  subprocesses  is  not  well 
addressed.  The  focus  of  design  and  manufacturing  is  to  develop  a  product  meeting  a  set  of 
functional  requirements,  which  are  themselves  determined  so  as  to  achieve  the  needs  of  the 
product's  user. 
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However,  success  in  a  product  development  process  is  not  determined  merely  by 
meeting  functional  (i.e.,  performance)  requirements  but  also  by  these  additional  attributes, 
both  of  which  we  desire  to  minimize: 

•  Product  Development  Lead  Time:  The  total  elapsed  time  for  the  completion  of 
the  product  development  process.  This  attribute  measures  how  fast  we  can 
progress  from  user  needs  to  the  reality  of  satisfying  those  needs.  In 
commercial  and  military  environments,  this  is  an  important  attribute  that 
measures  one's  competitive  advantage. 

•  Product  Life  Cycle  Cost:  The  total  cost  incurred  in  design,  manufacture, 
operation,  and  support  of  a  product  over  its  lifetime.  While  part  of  this  cost  is 
controlled  directly  in  the  product  development  process  (design  and 
manufacturing  cost),  the  remainder  (operations  and  support  cost)  is  indirectly 
influenced  by  this  process. 

In  spite  of  the  importance  of  these  attributes,  they  are  not  explicitly  dealt  with  in 
many  current  product  development  activities.  As  a  consequence,  the  current  design  process 
does  little  to  control  the  proliferation  of  uncertainties  that  result  in  unanticipated  increases  in 
lead  time  and  high  life  cycle  costs.  While  statistically  there  may  be  favorable  performance 
in  some  instances,  more  often  performance  in  one  or  both  of  these  measures  is  exceedingly 
unsatisfactory. 

To  have  better  control  of  these  two  attributes,  they  must  be  addressed  on  an  equal 
footing  with  performance  attributes.  This  is  the  primary  motivation  for  the  research 
reported  here.  We  argue  that  to  address  the  three  issues  (lead  time,  life  cycle  cost,  and 
satisfaction  of  needs),  we  must  develop  a  new  process  for  product  development  and  solve 
the  associated  management  problems  inherent  in  this  new  process. 

B .  CHARACTERIZATION  OF  PRODUCT  DEVELOPMENT  PROCESSES 

In  light  of  the  preceding  discussions,  it  is  useful  to  characterize  alternative  product 
development  processes  by  assigning  a  three-tuple  of  attributes  to  each  process.  This  will 
result  in  each  process  p  being  assigned  a  point  ap  =  (LT,  LCC,  NC),  where 

LT  =  Product  Development  Lead  Time 

LCC  =  Product  Life  Cycle  Cost 

NC  =  A  measure  of  failure  in  satisfying  functional  requirements. 


Clearly,  these  three  attributes  are,  in  some  sense,  in  conflict  with  each  other.  For 
example,  lowering  NC  might  necessitate  a  higher  development  cost  and  thus  tend  to 
increase  our  measure  in  the  second  dimension. 

One  might  attempt  to  incorporate  these  three  measures  into  a  scalar  index  that 
represents  the  absolute  measure  of  success.  However,  this  is  impractical,  if  not 
impossible,  since  these  attributes  relate  to  different  desires  of  the  user.  The  first  reflects  the 
desire  to  incorporate  the  most  recent  technological  advancements  into  the  product;  the 
second  attribute  reflects  the  total  cost  of  ownership  of  the  product;  while  the  third  reflects 
the  desire  to  buy  the  product  for  a  specific  need.  Thus  retaining  the  measure  of  success  as 
a  point  in  three  dimensional  space  is  best 

For  a  particular  initial  set  of  user  needs,  the  set  of  all  product  development 
processes  {p}  =  P,  which  result  in  a  product  satisfying  these  needs  may  be  characterized 
by  a  subset  of  three-dimensional  space: 

A  =  {ap,pe  P} 

We  say  that  process  P2  is  dominated  by  pj  if  api  £  a^,  i.e.,  each  component  of  apj 
is  less  than  or  equal  to  the  corresponding  component  of  a^.  In  this  case,  process  pj  is  said 
to  be  uniformly  better  than  process  p2.  If,  however,  there  are  i  and  j  such  that 

4] 2  4! but  4,  <  4, 

then  it  is  not  clear  which  process  is  to  be  preferred. 

Suppose  we  have  a  set  of  processes  {Pi,  P2, ...,  Pn}  which  can  be  applied  to 
develop  a  product  satisfying  the  same  requirements.  If  aPi,  i=l,...n,  can  be  computed, 

then  we  can  define  a  frontier  curve  in  the  attribute  space  A,  denoted  by  F,  such  that 

(1)  For  all  a  e  A,  there  exists  an  f  e  F  such  that  f  <,  a. 

(2)  If  f  €  F  and  there  exists  an  a  e  A  such  that  a  <  f,  then  a  =  f. 

In  a  two-dimensional  space,  such  a  frontier  curve  is  illustrated  in  Figure  II- 1. 

Clearly,  the  best  development  process  must  have  its  attributes  located  on  the  frontier 
curve.  More  than  one  process  may  achieve  this.  The  final  selection  from  among  the 
various  bests  is  based  on  trade-offs  among  the  attributes. 


Figure  11-1.  Frontier  Curve 


In  exploring  alternate  product  development  processes,  the  computation  of  the 
attribute  measures  associated  with  these  processes  may  not  be  very  accurate.  However, 
considering  these  attributes  up  front  will  serve  to  bring  out  the  major  issues  to  be 
considered  in  choosing  product  development  alternatives.  Also,  the  notion  of  a  frontier  line 
guides  us  in  making  decisions  within  the  development  process  in  trading  off  one  attribute 
with  another  when  conflict  exists. 

C .  ALTERNATIVE  PRODUCT  DEVELOPMENT  PROCESSES 

This  section  describes  two  fundamentally  different  classes  of  product  development 
processes-serial  approaches  and  overlapping  (or  concurrent)  approaches.  The  issues  of 
risk  and  uncertainty  must  be  treated  differently  in  each  approach. 


1 .  Serial  Approach 


This  approach  is  practiced  by  many  current  product  development  projects,  and  has 
been  essentially  standard  practice  in  the  United  States  until  recently.  As  such,  it  is  also 
referred  to  as  the  conventional  approach  [Ref.  2].  In  this  approach,  the  development 
project  is  divided  into  phases,  as  illustrated  in  Figure  II-2. 


One  way  to  reduce  lead  time  attribute  (and  indirectly  reduce  life  cycle  cost)  is  to 
focus  on  reducing  or  eliminating  iterative  loops.  To  do  this,  in  the  earlier  phases  team 
members  must  be  alerted  when  they  are  about  to  make  a  decision  that  will  trigger  an 
iterative  loop  in  a  later  phase.  This  requires  that  the  members  participating  in  the  early 
phase  have  full  knowledge  of  how  the  downstream  phases  would  be  performed  based  on 
their  decisions.  A  technological  approach  often  advocated  for  providing  this  knowledge  is 
development  of  a  knowledge-based  system  that  captures  all  of  the  problem  solving 
knowledge  in  each  phase.  Thus  when  a  member  in  an  upstream  phase  is  exploring  an 
alternative,  the  knowledge-based  system  can  be  invoked  to  examine  whether  such  an 
alternative  will  lead  to  downstream  conditions  that  trigger  an  iterative  loop. 

An  example  of  such  a  system  would  be  a  computerized  model  of  the  capabilities  of 
the  factory,  which  is  made  available  in  the  design  phase.  With  such  a  model,  the  designer 
could  evaluate  how  the  design  drives  production  requirements  and  identify  design  features 
that  adversely  affect  production  costs.  Another  example  is  the  generation  of  a  knowledge 
base  through  processing  of  field  failure  data  to  provide  the  designer  with  the  capability  to 
flag  design  features  that  lead  to  higher  support  costs  in  the  field. 

While  this  technological  approach  sounds  plausible,  there  are  several  drawbacks  to 
such  an  approach.  If  the  knowledge  base  does  not  contain  enough  information,  many 
subtle  situations  will  exist  that  cannot  be  handled.  With  the  current  state  of  technology,  it  is 
not  clear  whether  an  adequate  knowledge- based  system  can  be  developed.  Even  if  a 
sufficiently  complete  knowledge  base  comd  be  built  at  reasonable  cost  (a  highly 
questionable  assumption),  the  static  nature  of  such  a  knowledge  base  will  limit  its 
applicability  in  the  modem  environment  where  changes  occur  rapidly.  To  be  useful,  new 
insights  must  be  captured  fast  enough  for  the  knowledge-based  system  to  be  of  help  in 
problem  solving.  Maintaining  such  a  knowledge  base  in  a  fast-paced,  highly  competitive 
development  environment  could  be  a  very  difficult  and  costly  task. 

2 .  Overlapping  Approach 

The  overlapping  approach  is  practiced  by  some  of  the  more  successful 
manufacturers.  Studies  on  the  characteristics  and  nature  of  such  a  problem  solving 
approach  have  been  conducted  by  researchers  like  Hayes,  Wheelwright  and  Clark  [Ref.  2). 
The  following  paragraphs  describe  the  characteristics  of  such  an  approach  and  discuss  the 
management  problems  associated  with  such  an  approach. 
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In  this  approach,  we  allow  the  different  phases  to  be  overlapped  as  illustrated  in 
Figure  II-3.  A  distinguishing  feature  of  such  an  approach  is  that  when  a  downstream  phase 
is  carrying  out  a  function  in  parallel  with  the  upstream  phase,  information  transmission  is 
mostly  one  way  (up  to  down)  in  the  beginning,  but  then  when  the  downstream  phase  picks 
up  momentum,  two-way  communication  will  be  established  among  the  two  phases’ 
members. 


Figure  11-3.  Overlapping  Approach 

While  the  problem  of  the  iterative  loops  between  phases  that  occurs  with  the  serial 
approach  is  resolved  readily  using  the  overlapping  approach,  a  new  set  of  problems  are 
introduced.  In  the  serial  approach,  a  phase  begins  when  the  prior  phase  is  completed; 
however,  in  the  overlapping  approach,  the  time  when  a  phase  can  be  started  is  su 
management  control.  Note  that  each  phase  begins  while  the  prior  phase  has  not  yet  been 
completed,  and  thus  each  phase  has  to  allow  for  contingencies  due  to  uncertain  inputs  from 
the  earlier  phases.  Similarly,  earlier  phases  must  be  willing  to  release  current  solution 
proposals  to  later  phases  to  see  whether  conflicts  may  arise.  If  conflicts  arise,  the  members 
within  the  teams  must  resolve  them  in  a  cooperative  manner.  Thus,  it  is  imperative  that  all 
team  members  in  different  phases  know  the  overall  objective  or  goal  of  the  development 
project-what  the  product  requirements  and  the  relative  trade-offs  among  the  three  attributes 
are. 
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Moreover,  the  ending  of  each  phase  is  not  well  defined,  but  because  of  the 
overlapping  nature,  the  official  ending  of  each  phase  is  not  at  all  crucial.  As  long  as 
conflicts  can  be  resolved  when  they  arise,  one  can  assume  that  all  phases  end  at  the  same 
time.  For  each  phase,  the  activity  intensity  level  might  have  a  profile  such  as  is  given  in 
Figure  II-4.  The  coordination  of  the  activity  profile  in  each  phase  is  a  major  management 
issue. 


Figure  11-4.  Activity  Profile  Within  a  Phase  Duration 

The  overlapping  approach  will  greatly  reduce  iterative  loops,  but  each  individual 
phase  may  take  a  longer  period  of  time  to  complete.  The  overlapping  nature  of  the  process 
and  the  reduction  of  iterative  loops  will,  in  general,  lead  to  a  shorter  total  development  lead 
time,  and  the  reduction  of  iterative  loops  will  also  result  in  a  lower  development  cost. 
Bringing  in  downstream  knowledge  (e.g.,  manufacturability)  will  also  improve  the  chances 
of  reducing  overall  product  life  cycle  cost.  Therefore,  to  meet  the  same  performance 
criterion,  the  overlapping  approach  should  offer  the  opportunity  to  both  reduce  LT  and 
reduce  LCC.  Thus  all  else  being  equal,  we  argue  that  a  serial  development  process  will  be 
dominated  by  a  well-managed  overlapping  development  process--we  emphasize  well- 
managed  because  the  overlapping  process  leads  to  a  greater  demand  for  management 
control. 
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D.  MANAGEMENT  ISSUES 


The  increased  demand  for  management  control  arises  from  the  greater  uncertainties 
faced  by  members  within  each  phase-the  members  have  to  deal  with  a  large  degree  of 
ambiguity  in  their  problem  solving  activities  at  the  beginning.  However,  as  time 
progresses,  the  ambiguity  is  reduced.  When  much  ambiguity  exists,  the  team  members 
need  to  provide  for  flexibility  in  their  activities,  such  as  investigating  alternative  paths  and 
building  in  buffers  to  allow  for  change.  When  the  ambiguity  has  been  reduced  to  some 
threshold  level,  problem  solving  activities  can  then  be  focused  on  considerations  of 
optimization. 

Such  a  problem  solving  process  is  analogous  to  the  funnel  process  [Ref.  2],  except 
in  this  case,  we  are  dealing  with  the  development  of  a  specific  product,  rather  than  the 
selection  of  new  ideas  or  innovations  to  be  further  developed  and  marketed.  In  the  case  of 
a  design  project,  the  degree  of  flexibility  to  be  introduced  in  the  beginning  of  the  funnel 
process  is  direcdy  proportional  to  the  level  of  ambiguity  the  team  members  have  to  face  in 
the  beginning  of  the  phase  and  inversely  proportional  to  the  cost  of  introducing  such 
flexibility.  A  major  management  issue  arises  in  controlling  the  shape  of  the  funnel-the 
dynamic  reduction  in  ambiguity  over  time. 


In  the  overlapping  approach,  control  on  the  degree  of  flexibility,  as  time  advances, 
is  part  of  the  problem  solving  activity.  However,  this  is  a  team  problem  solving  activity  as 
opposed  to  an  individual  problem  solving  activity.  The  major  issue  here  is  communication 
among  team  members  in  different  phases  and  resolution  of  conflicts  among  teams  when 
they  arise.  Downstream  members  must  provide  critical  review  of  a  proposed  decision  that 
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is  about  to  be  made  by  the  upstream  members,  regarding  constraints  that  the  decision  may 
impose  on  their  problem  solving  activities,  which  might  seriously  affect  any  of  the  three 
process  attributes  (LT,  LCC,  or  NC).  In  addition,  they  may  wish  to  provide  suggestions, 
when  appropriate,  on  variations  of  the  proposed  upstream  decision  that  will  lead  to  a 
uniformly  better  solution. 

To  facilitate  addressing  such  management  issues,  we  need  to  develop  a  more 
structured  framework  into  which  the  problem  can  be  cast  for  solution.  The  notions  of  risk 
and  uncertainty  must  be  more  precisely  defined  and,  to  the  extent  possible,  quantitative 
methods  for  management  of  risk  developed.  We  begin  such  an  undertaking  in  the  next 
chapter,  where  we  define  basic  concepts  of  risk  and  uncertainty  and  formulate  a  simple 
structure  for  dealing  with  these  concepts. 
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in.  BASIC  CONCEPTS  OF  RISK  AND  RISK  EVALUATION 


A.  TYPES  OF  RISK 

The  risks  in  product  development  can  be  broadly  classified  as  market  risk, 
development  risk,  and  technology  risk.  Market  risk  refers  to  the  risk  that  the  product 
produced  may  not  meet  the  market  needs  or  capture  significant  market  share.  Development 
risk  is  the  risk  that  the  development  project  may  take  too  long  or  be  too  costly.  Technology 
risk  is  the  risk  that  advanced  technology  cannot  be  successfully  incorporated  into  the  new 
product.  The  sources  of  these  risks  are  different,  yet  they  all  influence  the  success  of  the 
product  development  project. 

As  an  example  of  market  risk,  the  design  team  may  face  the  problem  of  upstream 
uncertainty  in  user  requirements.  The  design  team  may  start  designing  the  product  based 
on  a  set  of  requirements  provided  by  marketing.  Midway  through  the  design,  certain 
requirements  may  be  modified.  These  changes  could  be  of  such  magnitude  that  a  total 
redesign  of  the  product  must  be  undertaken,  resulting  in  significant  schedule  slippage  and 
increased  development  cost,  which  could,  in  turn,  cause  a  serious  competitive 
disadvantage.  To  handle  this  problem,  the  members  of  the  development  team  must 
recognize  the  uncertainty  in  requirements  in  the  initial  design  phases  and  make  provision 
for  handling  such  uncertainty. 

Development  risk  is  related  to  the  uncertain  downstream  effect  of  decisions  made 
earlier  in  the  development  process.  For  example,  the  design  team  could  specify  a  certain 
part  in  the  design  that  could  be  built  by  the  company  or  purchased  from  an  outside  vendor. 
Should  the  company  choose  to  buy  the  part  from  a  vendor,  there  is  risk  associated  with  the 
level  of  quality  that  the  vendor  can  deliver  and  the  continued  existence  of  the  vendor  in  the 
market  Adverse  part  quality  could  lead  to  a  loss  of  future  sales  for  the  product  developer. 
The  business  failure  of  a  critical  supplier  could  lead  to  significant  costs  due  to  loss  of 
production  capacity  and  significant  start-up  costs  for  providing  for  alternative  sourcing. 
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To  illustrate  technology  risk,  consider  a  situation  in  which  a  new  technology,  under 
development  by  the  R&D  group,  promises  greatly  improved  product  cost  if  incorporated 
into  the  product  The  product  design  team  may  design  the  product  in  parallel  with  the 
activities  of  the  R&D  group,  assuming  that  the  technology  will  be  available  at  a  certain 
time.  Also,  the  competitive  situation  may  be  such  that  achieving  the  planned  product 
introduction  time  is  critical.  If  the  new  technology  does  not  become  available  as  planned, 
the  design  team  will  be  forced  to  go  back  to  a  conventional  design  that  is  not  dependent  on 
the  new  technology.  The  development  schedule  will  likely  slip  and  additional  redesign 
costs  will  be  incurred.  Moreover,  a  significant  market  opportunity  may  be  lost 

These  above  examples  share  certain  common  characteristics.  Design  decisions 
must  be  made  in  the  face  of  uncertainties  (upstream,  downstream,  or  technological).  A  key 
problem  in  the  design  process  is  to  maintain  the  risks  at  an  acceptable  level  while 
optimizing  expected  product  performance.  Pure  design  optimization  for  performance, 
without  explicit  consideration  of  risk,  can  lead  to  disaster.  Thus  the  success  of  a  product 
development  project  depends  on  not  only  engineering  creativity  and  knowledge  but  also 
management's  capability  to  manage  the  risk  in  a  dynamic  manner.  This  chapter  describes 
the  fundamental  concepts  of  risk  management  in  product  development  and  develops  a 
systematic  approach  to  deal  with  the  problem. 

B .  RISK  MANAGEMENT  FOR  TWO-STAGE  PROCESSES 

In  this  section  a  simple  model  for  handling  the  management  of  uncertainty  in 
processes  with  two  phases  is  developed.  Examples  of  such  processes  include  product 
development  with  a  specification  team  that  communicates  requirements  to  a  design  team, 
processes  with  parallel  R&D  and  design  efforts  that  must  interact,  and  the  portion  of  a 
development  process  that  consists  of  the  interactions  of  a  design  team  with  a  manufacturing 
team.  In  the  next  chapter,  process  with  more  than  two  phases  are  considered. 

The  necessity  of  risk  taking  arises  from  the  fact  that  we  need  to  choose  a  specific 
course  of  action  in  the  face  of  uncertainties.  If  these  uncertainties  cannot  be  reduced  in 
time,  then  the  choice  of  appropriate  action  can  be  based  on  statistical  evaluation  only.  If  the 
uncertainties  can  be  reduced  in  the  future,  then  one  can  either  opt  to  wait  until  uncertainties 
are  reduced  to  a  threshold  level  before  proceeding,  or  one  can  select  a  course  of  action 
while  recognizing  that  uncertainties  can  be  reduced  or  even  eliminated  in  the  future.  In 
product  development,  if  we  choose  to  wait  until  uncertainties  are  reduced,  we  are 
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effectively  choosing  the  serial  process.  If,  however,  we  choose  to  proceed  while 
recognizing  that  uncertainties  may  be  reduced  or  eliminated,  we  are  led  to  the  overlapping 
process. 

Let  Xi  be  a  specific  option  to  be  taken.  Associated  with  Xj  is  a  parameter  set  Si 
which  represents  the  restrictions  on  future  options.  If  some  event  e  happens,  then  we  can 
choose  some  pe  Sj  so  as  to  optimize  a  certain  objective.  Let  us  single  out  cost  as  the 
objective  in  this  case.  Assume  that  we  can  develop  a  cost  model  (analytical  or  through 
simulation)  Q(p,e),  pe  Sj.  Then  associated  with  the  actual  event  e,  we  will  incur  a  cost 
that  represents  the  resulting  minimum  cost  if  event  £  actually  occurs. 

f.(e)  =  nun  C(p,e)  (1) 

Suppose  that  for  each  i=l,2....n,  representing  n  different  choices,  we  do  not  know 
what  the  actual  event  e  will  be.  We  can  evaluate  fi(£),  i=l,...n  as  £  varies  over  a  region. 
For  n=2,  possible  plots  are  illustrated  in  Figure  HI-1.  Now  the  question  is  whether  Xi  or 
X2  is  the  better  option.  The  choice  is  clear  if  we  know  that  Ee  A— Xi  is  optimal.  If, 
however,  £e  B,  then  the  choice  is  less  clear. 

In  some  sense,  choosing  Xi  incurs  a  higher  risk- if  £«  A,  but  ee  B,  then  choice  of 
Xi  may  lead  to  a  disaster,  whereas  a  choice  of  X2  gives  acceptable  performance  over  a 
wider  range.  Thus  the  cost  sensitivity,  f,(*),  affects  the  risk  associated  with  the  decision 
Xj.  However,  the  risk  of  choosing  Xi  depends  also  on  our  assessment  of  where  £  will  lie. 
If  we  assess  that  Ee  F,  where  F  is  a  proper  subset  of  A,  then  choosing  Xj  has  no  risk  at  all. 


Let  7t(£)  be  a  distribution  of  the  exogenous  event  E.  We  can  calculate 


f.  =  J  f(£)7C(£)d£ 

(2) 

0f  =  J(fi(£)-fi)27t(£)d£ 

(3) 

The  risk  associated  with  Xi  is  measured  by  o^.  If  of  is  large,  then  we  may  anticipate  a  big 
loss  if  a  negative  outcome  occurs. 

From  (3),  we  note  that  of  is  dependent  on  the  shape  of  fj(£)  as  well  as  7t(£).  If  fj(e)  is 
reasonably  flat  over  a  region  of  £  where  jc(e)  is  nonzero,  then  of  is  small.  Thus  risk  can  be 
controlled  by  selecting  a  specific  option  Xj,  which  results  in  a  reasonably  flat  fj(£)  or  by 
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Figure  111-1.  Plots  of  f|(e) 


controlling  the  distribution  rt(e).  Usually,  the  selection  of  Xj  that  results  in  a  flat  fj(e)  will 

also  yield  a  fj(e)  whose  minimum  min  f.(e)  is  reflectively  high  as  compared  to  another 

e  1 

option  Xj,  whose  fj(e)  is  not  flat  but 

nun  f.(e)  <  min  f.(e)  (4) 

If  Jt(£)  is  not  controllable,  then  the  trade-off  between  Xj  and  Xj  is  between  lower  average 
cost  versus  higher  risk.  However,  if  K(e)  can  be  controlled,  then  one  may  seek  to  choose 
Xj  and  7t(e)  such  that  both  the  average  cost  and  risk  are  lowered. 

Referring  to  Figure  III- 1 ,  if  we  can  control  7t(e)  to  have  most  of  its  weight  within 
the  subset  A,  then  Xi  is  a  better  choice  than  X2,  from  the  average  performance  and  the  risk 
point  of  view.  It  should  be  clear  that,  from  the  example,  the  optimal  choice  of  option  is 
dependent  on  our  capability  to  influence  rt(e). 

Let  us  plot  f.  and  i=l,...,n  in  a  two-dimensional  space  as  in  Figure  III-2.  In  the 
plots  with  7t(e),  X4  and  X5  are  dominated  by  X2  and  possibly  Xi.  Therefore,  to  select  the 
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Figure  111*2.  Plots  of  f,  vs.  of  as  Uncertainty  Changes 


appropriate  options,  we  need  only  to  consider  Xi,  X2,  and  X3  and  conduct  trade-offs 
between  average  cost  and  risk  exposure.  The  plots  for  f.  vs.  o2  will  change  as  the 

distribution  on  £  changes.  In  Figure  3H-2,  we  show  two  plots  with  different  distributions: 
tt(e)  and  tt'(e).  Note  that  with  X4  dominates  X2  and  X3;  and  the  three  options 
subject  to  trade-off  consideration  are  Xi,  X4,  and  X5.  From  Figure  IH-2,  we  would  likely 
conclude  that  the  pair  (X4, 7t'(*))  is  the  best  option. 

C .  APPLICATION  TO  THE  THREE  CATEGORIES  OF  RISK 

This  section  describes  how  the  preceding  formulation  can  be  applied  to  the  three 
categories  of  risk  in  product  development  illustrated  at  the  beginning  of  this  chapter. 

1 .  Uncertainty  in  Requirements 

In  the  overlapping  problem-solving  approach,  the  designer  will  start  designing  the 
product  while  the  requirements  for  the  product  are  not  fully  specified.  In  fact,  one  of  the 
notions  of  ULCE  is  that  the  designer  should  participate  in  helping  to  determine  those 
requirements. 

In  this  case,  e  will  represent  certain  parameters,  such  as  performance,  shape, 
tolerance,  and  supportability  which  are  subject  to  uncertainty.  Suppose  there  are  three 
basically  different  design  approaches  that  can  be  taken,  denoted  by  Xi,  X2,  X3.  The  set  Sj 
associated  with  Xi  determines  the  flexibility  that  the  designer  has  within  the  constraints 
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imposed  by  that  approach.  It  is  assumed  that  the  requirements  will  be  eventually  finalized 
and  the  corresponding  optimum  design  will  be  developed  within  the  approach  taken. 

The  curve  fi(e)  represents  an  engineering  assessment  made  by  the  design  team  of 
the  resulting  cost  associated  with  approach  Xj  if  eventually  the  requirement  is  e.  The 
specification  team  comes  up  with  a  distribution  7t(e),  which  is  passed  on  to  the  design  team 
(feedforward  to  downstream).  The  design  team  takes  7t(e)  as  given  and  generates  a  plot 
like  Figure  ID-2  from  which  they  either  recommend  an  approach  to  management  that  has  a 
reasonable  trade-off  between  average  cost  and  relatively  low  risk  or  suggest  to  the 
requirement  specification  team  that  they  modify  the  distribution  7t(e)  to  7t'(e)  which  will 
result  in  lower  risk  and  lower  average  cost  (feedback  to  upstream). 

The  negotiation  between  the  requirement  specification  team  and  the  design  team  is 
focused  on  the  interplay  between  the  uncertainty  distribution  K(e)  and  the  resulting  plots  as 
in  Figure  III-2.  Basically,  the  suggested  distribution  7t'(e)  will  require  the  requirements 
specification  team  to  reallocate  effort  to  reduce  the  most  sensitive  uncertainty  from  the 
design  perspective.  This  may  or  may  not  be  feasible  from  the  requirements  specification 
team's  point  of  view.  However,  a  plot  like  Figure  IE-2  can  be  used  as  a  catalyst  to  derive 
consensus.  Figure  m-3  illustrates  the  process  described  above. 


Figure  111*3.  Handling  of  Uncertainty  in  Requirements 


2 .  Uncertainty  in  Parts  Availability 

When  uncertainty  about  parts  availability  exists,  the  design  team  must  decide 
whether  they  should  design  the  product  based  on  standardized  parts  that  are  readily 
available  or  design  the  product  by  specifying  the  parts  needed  and  ask  certain  vendors  to 
manufacture  those  parts.  Let  Xi  be  the  approach  of  using  standardized  parts  and  X2  the 
other  approach.  The  total  life  cycle  cost  of  the  product  consists  of  design  cost, 
manufacturing  cost,  operations  cost,  and  support  costs.  In  this  case,  the  uncertainty  is  the 
future  availability  of  parts.  Let  e  be  the  average  lead  time  for  parts  when  needed.  If  e  is 
large,  then  high  support  costs  will  be  incurred. 

Restricting  parts  use  to  standardized  parts  may  incur  higher  design  and 
manufacturing  costs.  Assume  that  under  both  design  approaches  we  are  required  to  meet 
the  same  requirements  for  reliability  and  maintainability.  Then,  assuming  that  fi(e)  is  a 
measure  of  product  life  cycle  cost,  we  will  have  a  situation  as  illustrated  in  Figure  IH-4. 
The  slope  of  both  curves  will  depend  on  the  degree  of  reliability  and  maintainability 
required  in  the  product  specification.  For  e~0,  life  cycle  cost  will  be  dominated  by  the 
design  and  manufacturing  costs,  and  in  this  case,  the  Xi  approach  will  incur  a  higher  cost. 
However,  as  e  becomes  large,  the  total  cost  will  be  dominated  by  the  maintenance  and 
support  costs.  In  general,  standardized  parts  imply  lower  component  replacement  costs, 
thus  f2  will  overtake  fi  as  e  becomes  large. 

In  this  case,  the  distribution  on  e  depends  on  the  design  choice.  Jti(e),  the 
distribution  on  availability  if  the  parts  are  standardized,  is  likely  to  be  concentrated  on  low 
values  of  e.  7t2(e),  the  distribution  on  availability  if  the  parts  are  not  standardized,  is  likely 
to  be  concentrated  on  high  values  of  e.  Moreover,  7ti(e)  is  most  likely  determined  by  the 
structure  of  the  standardized  vendor's  market  and  thus  will  be  less  controllable;  whereas 
7t2(e)  may  depend  on  other  elements  such  as  the  relationship  with  the  vendor  and  the 
specificity  of  parts  required  and  therefore  will  be  more  controllable. 

As  before,  we  can  compute 

f.  =  J  f.(e)  7Cj(e)de 
=  J  (f(e)  -  l)Z  xcj(e)de 
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Figure  111-4.  Total  Life  Cycle  Cost  as  a  Function  of  Parts  Availability 

to  represent  the  average  cost  and  risk  associated  with  parts  availability.  Note  that  the 
optimum  choice  is  not  clear,  since  it  depends  on  the  following: 

•  The  slopes  of  the  curves  fi(e),  f2(E)  (reliability  and  maintainability 
requirements) 

•  The  intercepts  of  the  curves:  fi^0),  (design  and  manufacturing  costs) 

•  The  distribution  (•)  (market  structure  of  standardized  parts) 

•  The  controllability  of  7t2(*)  (capability  of  influencing  vendor's  performance). 

In  general,  if  there  are  special  features  of  a  component  that  are  unique  and  absolutely 
necessary,  then  standardized  parts  may  not  be  readily  available,  in  which  case  X2  may  be 
the  better  choice.  The  analysis  indicates  that  in  such  cases  more  emphasis  should  be 
devoted  to  tightening  the  relationship  with  the  vendor  contracted  to  provide  the  component. 
On  the  other  hand,  if  standardized  components  can  be  used,  then  most  likely  iti(e)  will  be 
clustered  at  a  low  value  of  e,  which  implies  that  Xi  is  a  better  choice.  For  a  product  that 
has  many  component  parts,  the  analysis  can  be  used  to  determine  which  component  parts 
should  be  obtained  from  standardized  markets  and  which  parts  from  custom  or  semi- 
custom  markets.  Such  a  determination  will  provide  a  guideline  for  product  design.  This 


case  illustrates  how  downstream  uncertainty  can  influence  an  upstream  decision.  This 
example  is  discussed  in  more  detail  in  the  next  chapter. 

3.  Uncertainty  in  New  Technology 

Suppose  that  the  R&D  group  is  developing  a  new  technology  which,  if  successful 
and  used  in  the  product  to  be  developed,  will  tremendously  reduce  the  overall  product  cost. 
The  product  can  also  be  developed  without  the  use  of  such  new  technology,  but  the  overall 
product  cost  will  be  much  higher.  However,  the  product  development  team  does  not  know 
the  time  e  when  the  R&D  group  can  make  the  new  technology  available.  The  absolute 
deadline  for  product  introduction  is  specified  as  T.  Should  the  product  be  introduced  at  an 
earlier  time  t,  then  the  company  will  attain  a  value  v(t)  >  0,  for  all  t  £  T  that  is  monotonic 
decreasing  and  v(T)  =  0.  The  maximum  resources  that  the  product  development  manager 
can  draw  on  to  complete  the  project  are  constrained. 

The  project  manager  estimates  that  if  he  uses  the  maximum  capacity  in  developing 
the  product  via  the  conventional  approach  (does  not  use  the  new  technology),  it  will  take 
Ti<T  to  complete  the  product  development;  whereas  if  he  uses  the  maximum  capacity  to 
develop  the  product  and  assumes  the  new  technology  is  available,  then  he  will  require 
T2€  [Ti,T]  to  complete. 

The  manager  has  several  options.  The  first  option,  X],  is  to  allocate  the  full  team  in 
developing  the  product,  assuming  that  the  new  technology  is  available.  However,  at  time 
t=T-Ti,  if  the  new  technology  is  still  not  available,  then  he  must  abandon  the  original 
development  and  allocate  the  full  team  to  the  conventional  approach  to  meet  the  deadline  T. 
We  can  plot  fi(e)  as  shown  in  Figure  III-5.  Here,  e  stands  for  the  time  that  the  new 
technology  becomes  available.  If  the  new  technology  is  made  available  before  T-Ti,  then  it 
will  be  used.  We  assume  in  this  example  that  sufficient  flexibility  is  built  into  the  product 
development  process  so  that  the  cost  of  incorporation  of  new  technology  is  independent  of 
the  time  when  it  is  made  available. 

The  second  option,  X2,  is  to  allocate  the  full  team  in  developing  the  product  without 
assuming  that  the  new  technology  is  available;  but  then,  once  it  is  available  (before  T-T2) 
switch  the  full  team  to  the  approach  of  utilizing  the  new  technology.  By  T-T2,  if  the  new 
technology  is  still  not  available,  then  it  is  too  late  to  adopt  the  new  technology.  Note  that  in 
this  case  if  the  new  technology  is  not  available  before  T-T2,  the  team  will  continue  its 
original  effort  and  will  complete  the  development  at  Tj<T.  The  value  v(Tj)  can  be  used  to 


m-9 


offset  the  total  cost  and  thus  produce  the  curve  f2(e)  as  in  Figure  113-5.  As  compared  to 
Xi,  if  the  new  technology  is  not  available  by  T-T2,  the  X2  approach  will  finish  the 
development  later. 


Figure  111-5.  Cost  as  a  Function  of  the  Time  When  New  Technology  is  Available 

Another  option  is  to  split  the  total  resources  up  into  two  teams.  One  team  assumes 
that  the  new  technology  is  available,  and  the  other  team  assumes  that  the  new  technology  is 
not  available.  The  two  teams  will  merge  into  one  under  different  events.  If  the  new 
technology  is  available  early  enough  so  that  it  can  be  used  and  the  deadlines  still  met,  then 
the  two  teams  will  merge  and  proceed  using  the  new  technology;  otherwise  the  teams  will 
merge  and  proceed  without  the  new  technology.  The  maximum  waiting  time  before 
merging  without  the  availability  of  new  technology  is  dependent  on  the  relative  size  of  these 
two  original  teams.  One  can  view  Xi  and  X2  as  the  two  extremes  of  this  option. 
Conceptually  we  can  have  a  continuous  set  of  options.  For  illustrative  purposes,  we  shall 
only  plot  one  such  f3(e)  in  Figure  IE-5. 

The  optimal  choice  depends  on  ;c(e),  the  distribution  of  the  time  availability  of  the 
new  technology.  If  7t(e)  is  concentrated  on  lower  values  of  £,  then  Xj  is  optimal.  As  7t(£) 
is  shifted  to  the  right,  X3  would  be  optimal.  A  further  shift  of  7t(e)  to  the  right  will  make 
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X2  become  optimal.  This  implies  that  input  from  the  R&D  is  critical  in  determining  the 
optimal  approach.  By  having  the  design  team  work  closely  with  R&D,  we  may  be  able  to 
shift  7t(e)  to  the  left,  which  will  increase  the  chance  that  the  new  technology  will  be  adopted 
and  result  in  a  much  lower  cost.  Using  the  analysis,  the  manager  can  determine  such  an 
optimal  resource  allocation. 

If  the  R&D  is  conducted  by  another  company  (supplier),  then  the  analysis  can  be 
used  to  determine  the  value  of  having  the  product  team  interacting  with  and  even  helping 
the  supplier's  R&D  team  to  make  the  new  technology  available  earlier. 

The  preceding  analysis  was  based  on  the  assumption  that  T2e  [Ti,T].  If  T2<Ti<T, 
then  instead  of  Figure  III-5,  we  have  Figure  III-6.  Similar  conclusions  can  be  deduced; 
however,  the  dependency  of  optimal  option  on  7t(e)  will  be  different. 


Figure  HI-6.  Variation  of  Figure  111-5  When  Ti  >  T2 
•  D.  GENERAL  REMARKS 


The  basic  concept  described  in  the  preceding  section  can  be  a  powerful  tool  in  the 
management  of  the  product  development  process.  The  next  chapter  describes  how  the 
approach  can  be  easily  extended  to  handle  multiple  overlapping  phases.  Even  though  our 
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discussion  focuses  on  cost  as  the  primary  variable  of  interest,  a  similar  approach  can  be 
taken  to  deal  with  development  lead  time. 

The  approach  described  in  this  section  is  similar  in  concept  to  the  Taguchi  approach 
for  parameter  design  [Ref.  4],  In  Taguchi's  approach,  a  loss  function  is  computed  based 
on  the  deviations  of  certain  product  characteristics  from  target  values  in  a  noisy  (random) 
environment.  The  objective  is  to  choose  a  set  of  design  parameters  to  minimize  the 
expected  loss.  Our  a2  is  analogous  to  the  Taguchi  loss  function.  In  the  approach  outlined 
in  this  chapter,  the  design  parameters  are  subject  to  control,  and  a  portion  of  the  random 
environment  may  be  subject  to  management  control.  While  the  design  engineer  focuses  on 
selection  of  design  parameters  to  minimize  the  loss  function,  the  management  focus  should 
be  on  controlling  the  environment  to  allow  the  engineers  to  do  a  better  job.  Close 
interaction  between  engineers  and  managers  is  the  key  to  achieving  an  optimum  design. 
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IV.  INTEGRATION  OF  UPSTREAM  AND  DOWNSTREAM 

UNCERTAINTIES 


» 


A.  THREE-PHASE  PROCESSES 

In  this  chapter,  we  consider  a  three-phase  process  in  which  the  activities  of  the 
second  phase  (which  for  our  purposes  we  assume  to  be  the  design  phase)  are  affected  by 
uncertainties  in  output  from  the  first  phase  (an  upstream  phase),  and  themselves  affect 
uncertainties  in  the  third  phase  (a  downstream  phase).  This  situation  is  illustrated  in  Figure 
IV- 1. 


Figure  IV-1.  Interactions  Among  Phases  in  a  Development  Process 


I.  Upstream  Phase  and  Design  Phase 

At  the  beginning  of  the  design  phase,  the  upstream  phase  will  not  have  determined 
its  final  output,  the  requirements  specification  e^,  and  will  only  be  able  to  provide  a 

distribution  7t(eu),  which  assigns  relative  likelihoods  over  several  possible  requirements 
specifications.  The  degree  of  variability  of  k  is  a  measure  of  the  uncertainty  in 
requirements  that  is  faced  by  the  design  team. 


IV-1 


As  noted  in  the  preceding  chapter,  in  attempting  to  design  to  a  particular  set  of 
requirements,  the  designers  will  choose  a  design  concept  Xj,  and  within  this  concept  (or 
approach)  will  seek  to  identify  values  for  a  set  of  parameters  p  e  Si,  which  optimizes  the 
design  within  the  constraints  Si  imposed  by  the  concept  Xj.  Note  that  we  use  the  term 
"optimize"  in  a  general  way.  Strict  mathematical  optimization  is  not  necessarily  implied.  In 
general  we  assume  that  optimize  means  to  determine  a  feasible  set  of  parameters  p  e  Si  (a 
"satisficing"  solution),  which  appears  to  be  the  best  approach  possible  given  the  available 
knowledge  and  resources  of  the  design  team. 

Eventually  the  upstream  phase  will  be  concluded,  with  the  final  requirements  being 
specified  as  .  We  shall  refer  to  the  process  of  proceeding  from  the  distribution  7t(eu)  to 
as  the  freezing  of  requirements.  After  this  point,  the  design  team  will  then  proceed  to  a 
final  design  p*.  This  process  is  called  freezing  the  design. 

2 .  Downstream  Phase 

For  any  p  e  Si,  uncertainties  will  also  arise  due  to  downstream  considerations.  We 
shall  denote  such  uncertainty  by  £<j.  As  examples,  e<i  could  represent  uncertainties  in  the 
manufacturing  process  or  uncertainties  in  the  future  availability  of  certain  components  or 
parts.  The  distribution  of  such  uncertainties  is  influenced  by  the  design  approach  taken  (i) 
and  the  choice  of  parameters  p  e  Si.  We  shall  denote  this  distribution  by 

7t.(ed!  p) 

Note  that  p  is  also  a  function  of  eu,  so  this  can  also  be  represented  by 

*i(ed  I  P(eu))  • 

In  most  deterministic  design  approaches,  the  final  design  would  be  obtained  by 
solving  a  deterministic  optimization  [Refs.  11, 12]  of  general  form: 

min  f(p,  e*) 

s.t.  g(p,  e*)  £  0 

This  approach  ignores  the  downstream  uncertainties  that  will  be  influenced  by  the  choice  of 
P(<)- 

At  the  beginning  of  the  downstream  phase,  the  downstream  team  will  face 
uncertainties  in  the  output  from  the  design  phase.  After  the  design  is  frozen  at  p*, 
however,  the  downstream  team  may  then  optimize  its  activities  for  the  design  p*.  When 
the  downstream  phase  is  the  production  phase,  this  amounts  to  optimizing  the  production 
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process  for  a  given  design.  At  this  point,  techniques  for  continuous  production  process 
improvement  become  operational.  These  activities  serve  to  change  the  form  of 
*i(ed  I  P(<))- 

3.  Integration  of  Phases 

As  in  the  two-phase  processes  discussed  in  Chapter  II,  the  key  issue  in  handling 
both  upstream  and  downstream  uncertainties  involves  proper  management  of  the  reduction 
in  these  uncertainties  over  time.  In  the  early  part  of  the  design  phase,  the  design  team 
interacts  only  with  the  upstream  requirements  team.  In  the  middle,  the  design  team  will 
interact  with  both  upstream  and  downstream  teams.  After  the  upstream  input  is  frozen,  the 
design  team  will  interact  mainly  with  the  downstream  team.  In  the  latter  portion,  if  the 
downstream  phase  is  the  production  phase,  the  design  activity  will  include  optimization  of 
the  design  for  production.  Production,  on  the  other  hand,  will  seek  to  optimize  production 
processes  given  the  design.  Since  both  the  design  and  production  processes  are  uncertain 
at  first,  continual  interaction  between  teams  must  occur  to  reduce  this  uncertainty  and  allow 
convergence  to  an  overall  solution.  This  process,  in  the  case  of  design  and  production,  is 
known  as  simultaneous  engineering. 

Simultaneous  engineering  involves  reducing  downstream  uncertainties  over  time. 
However,  it  should  be  noted  that,  unlike  the  upstream  case,  all  downstream  uncertainties 
will  not  be  totally  resolved.  Until  the  product  life  cycle  is  complete,  some  downstream 
uncertainties  will  remain. 

To  manage  the  process  of  reduction  of  uncertainty,  we  need  to  develop  a  strategy. 
To  develop  such  a  strategy,  we  shall  begin  by  considering  the  design  phase  and  its  problem 
of  developing  an  optimal  design  in  the  face  of  up  ,tream  and  downstream  uncertainties.  To 
do  this,  we  need  to  develop  a  metric  to  measure  what  we  mean  by  optimality. 

B .  PARAMETER  OPTIMIZATION 

In  this  section  we  will  develop  an  approach  to  optimizing  designs  in  the  face  of 
downstream  uncertainties,  and  in  the  next  section  we  address  management  issues  of  a 
development  process  based  on  this  approach. 


1.  General  Product  Development  System  Model 


Figure  IV-2  depicts  a  conceptual  model  of  the  product  development  process,  which 
highlights  the  features  of  that  process  of  interest  to  us. 


Figure  IV-2.  Development  Process  System  Model 

In  this  model,  the  system  produces  a  response  y,  which  is  a  random  vector  of  outputs 
driven  by  the  design  (concept  selection  and  choice  of  design  parameters)  input  requirement 
specifications  that  are  subject  to  uncertainty  for  some  period  of  time,  and  downstream 
factors  that  are  also  subject  to  uncertainties  that  are  conditional  on  the  design  approach  and 
parameters  chosen.  Our  objective  is  to  control  the  inputs  and  choices  in  the  model  in  such  a 
way  to  produce  outputs  that  are  good  in  some  sense.  Our  options  include 

•  Managing  the  uncertainty  in  eu  (controlling  the  formal  process  for  determining 
the  product  requirements). 

•  Managing  the  downstream  uncertainty  to  the  extent  possible. 

•  Selecting  a  design  concept  i  with  an  appropriate  balance  of  expected 
performance  and  risk. 

•  Choosing  the  design  parameters  once  the  concept  has  been  selected. 


We  briefly  discussed  the  first  three  of  these  options  in  the  last  chapter,  and  they  are 
addressed  again  in  more  depth  later  in  this  chapter.  In  this  section,  we  will  concentrate  on 


IV-4 


accomplishing  the  last  point  in  the  face  of  downstream  uncertainty,  assuming  the  concept  i 
and  the  requirements  specification  eu  are  fixed. 

2 .  Response  Function 

While  there  are  many  possible  ways  to  measure  the  response  of  the  system,  we 
propose  that  the  vector  y  should  consist  of  three  major  components: 

•  a  vector  yx  of  physically  measurable  target  performance  characteristics  of  the 
product  being  developed 

•  yc,  the  product  life  cycle  cost 

•  y\,  the  lead  time  for  delivery  of  the  first  product. 

Thus  y  =  (yx,  yc,  yi)  in  our  formulation. 

The  vector  yx  would  consist  of  product  attributes  such  as  weight,  range,  and 
maximum  speed  for  a  product  such  as  an  aircraft.  For  other  types  of  products,  other 
measures  would  be  appropriate.  The  important  thing  is  that  we  must  be  able  to  physically 
measure  yx  for  each  product  as  it  is  placed  in  service. 

In  contrast,  yc  cannot  be  physically  measured  at  the  time  of  introduction,  since  it 
depends  on  events  that  have  not  yet  occurred,  such  as  field  usage  factors  and  costs  and 
availability  of  manpower  and  spare  parts.  In  principle,  we  can  infer  the  effects  of  changes 
in  p  on  yx  through  experimentation,  but  this  is  not  possible  with  yc.  The  best  we  can  do  is 
to  predict  yc,  and  in  the  design  phase,  such  predictions  will  be  very  uncertain  at  best. 
While  the  absolute  values  of  yx  have  meaning,  predictions  of  yc  will  be  useful  only  in  a 
relative  sense~to  compare  and  rank  designs  whose  other  characteristics  are  equivalent. 

Lead  time  also  differs  from  yx.  Lead  time  may  be  predicted  during  the  design 
phase,  but  with  considerable  uncertainty.  At  the  time  of  product  introduction,  lead  time  is 
known,  but  by  then  it  is  too  late  to  change  it.  As  with  yc,  yx  is  a  factor  useful  in  ranking 

and  comparing  designs,  and  we  should  generally  seek  designs  with  the  lowest  value 
possible.  Product  introduction  time  considerations  often  determine  limits  for  lead  time. 
Using  lead  time  as  a  constraint  rather  than  as  part  of  our  objective  in  the  design  process 
may  be  more  appropriate. 

In  the  development  process  we  should  usually  seek  to  minimize  yc  and  minimize 
yx,  or  at  least  constrain  it  In  the  case  of  yx,  however,  we  usually  will  have  explicit  goals 
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or  target  values  provided.  These  values,  which  we  denote  by  yT(eu),  are  clearly  related  to 
the  requirements  and  also  to  the  design  concept  The  process  of  generating  yT  from  eu  is  a 

key  part  of  the  systems  engineering  process.  While  we  assume  that  this  process  is  given 
here,  the  development  of  better  methodologies  in  this  area  is  an  area  of  research  that 
deserves  more  attention. 

In  summary,  we  may  recast  the  design  parameter  optimization  problem  as: 

Seek  to  attain,  as  best  as  possible,  the  physical  performance  goals,  while 
minimizing  life  cycle  cost  and  not  exceeding  lead  time  constraints. 

Note  that  in  contrast  to  yT,  which  is  derived  from  the  specification,  yx  is  a  function  of  the 

design  concept  and  parameters,  eu,  and  e<i.  Thus,  yj  is  a  random  quantity.  The  degree  to 
which  we  attain  product  goals  will  vary  from  product  to  product-some  will  turn  out  well 
and  others  will  not  This  randomness  must  be  considered  in  solving  the  problem. 

3 .  Mathematical  Formulation  of  Parameter  Optimization  Problem 

The  problem  stated  above  may  be  mathematically  formulated  in  a  variety  of  ways. 
One  approach  would  be  to  formulate  the  problem  using  the  goal  programming  approach 
(for  example,  see  Mistree,  et  al.  [Ref.  3]).  In  this  paper,  following  the  approach  taken  by 
Taguchi  [Ref.  4],  we  will  compute  a  measure  of  failure  to  attain  the  goal  yT  based  on  a 

quadratic  function  of  the  absolute  deviation  of  the  actual  performance  characteristics  from 
the  target  vaules.  This  measure  is  thus  defined  as 

Lip(eu.  ed)  =  llyT-yTl|2  =  I(yT(i)  -  yT(i))2 

Li(P  measures  the  sum  of  the  squared  derivations  of  physical  product  performance 
characteristics  from  the  target  goals.  The  Taguchi  method  [Refs.  4,  5,  6,  7]  of  parameter 
optimization  seeks  to  minimize  the  expected  loss  function  in  the  presence  of  external  noise. 
In  our  formulation,  this  translates  into: 

ran  Ed[L  (e„,  ed)]  (1) 

p  €  o« 
r  I 

where  Ed(f)  =  J  f(ed)7t.(ed  I  p(eu))d£d  . 

Q 
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An  alternate  expression  for  the  minimization  (1)  is  given  by 


where  Vard(f)  =  j  (f(e  )  -  Ed(f))2  7c.(ed)d£d . 

Cl 

The  minimum  value  for  (1)  or  (2)  is  denoted  by  o?(eu).  o?(eu)  is  considered  a 

measure  of  the  optimum  level  of  quality  attainable  with  design  concept  i  in  the  presence  of 
downstream  uncertainties  rti.  It  can  also  be  considered  as  a  measure  of  the  downstream 
risk  of  not  meeting  the  performance  requirements. 

Three  things  should  be  noted  about  this  approach.  First,  the  upstream  requirements 
specification  eu  is  treated  as  fixed.  Second,  the  downstream  uncertainty  distribution  is 
fixed.  Exogenous  changes  to  iti  are  not  considered  here.  Finally,  the  method  is  focused 
exclusively  on  physically  measurable  performance  characteristics.  Life  cycle  cost  and  lead 
time  are  not  considered.  Thus  the  minimization  problem  stated  in  (1)  and  (2)  addresses 
only  the  first  part  of  the  design  parameter  optimization  problem. 

To  extend  this  method,  let  us  first  consider  the  addition  of  life  cycle  cost  to  the 
problem.  Since,  from  the  previous  discussion,  life  cycle  cost  should  be  minimized  while 
attaining  good  quality,  we  propose  the  following  formulation.  Consider  the  following 
problem. 

min  E  (y  )  (3) 

peSi  d 

s-1-  Ed(Li,p(eu’ ed)) -5’5^ ofcu) 

Note  that  8  >  o^(eu)  guarantees  a  solution,  while  for  8  <  <P(eu)  there  is  no  solution.  For 
8  >  cP(eu),  let  y*(eu,  8)  denote  the  minimum  obtained  in  this  problem.  Then  it  is  clear  that 
for81S82^of(eu),  we  have 

y*(eu,82)^yc(eu,  Sp  • 

Thus,  the  relationship  between  y *  and  8  is  as  shown  in  Figure  IV-3. 
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Figure  IV-3.  Dependence  of  Minimum  Life  Cycle  Cost  on  Allowable  Quality 

If  we  consider  the  loss  function  o?(eu)  as  a  measure  of  quality,  we  see  that  the 

curve  in  Figure  IV-3  shows  the  trade-off  between  life  cycle  cost  and  allowable  quality 
(measured  by  5).  While  the  simple  optimization  in  (2)  by  itself  optimizes  quality,  the  cost 
of  attaining  this  optimum  may  be  very  high.  If  we  can  quantify  our  relative  desires  for 
quality  and  low  cost  by  weights  wc  and  wg,  then  we  can  compute  a  dissatisfaction  function: 

J.(yc,  8)  =  wcyc  +  Wg  8  (i  =  design  concept) 

Then  various  levels  of  dissatisfaction  correspond  to  the  family  of  lines  shown  in  Figure 
IV-3.  The  optimum  level  of  dissatisfaction  is  achieved  at  the  point  of  tangency  of  this 
family  of  lines  to  the  (y*,  8)  trade-off  curve.  This  is  found  by  solving  the  equation 

\ , 

38  wc 

Let  the  solution  be  denoted  8*.  Then  X  measures  the  price  we  pay,  in  terms  of  increased 
dissatisfaction,  for  a  unit  change  in  quality  near  the  optimum.  The  corresponding  cost  and 
dissatisfaction  levels  at  the  optimum  are 

yc(£u> 8*) 


J*(yc<eu>  =  wcyc*<eu’ 5+) +  wg  5* 


rv-8 


Since  5*  is  computed  by  an  optimization,  we  can  suppress  the  dependency  and  denote  the 
latter  quantity  by 

J-og 

If  we  wish  to  incorporate  lead  time  as  well  as  cost,  this  can  be  done  as  follows: 

Consider  the  problem: 

•  W2*0  ■  ?i +?2 - 1 

D  €  O.  L  J 

*  1 

s.t.  Ej(L.  _(e,„  ej)  £  8  >  o?(e„)  (3') 

An  analogous  development  to  the  one  given  above  for  cost  and  quality  will  lead  to  a  new 

*  *  ♦ 

dissatisfaction  function  J.  (£u)  =  wcyc  +  wg  5  +  wt  l  . 

We  shall  refer  to  the  function  J*(eu)  as  the  generalized  loss  function,  since  it 

incorporates  not  only  losses  due  to  poor  quality,  but  also  due  to  high  cost  and  excessive 
time  to  market  in  developing  the  product 

As  we  shall  see  in  section  C  of  this  chapter,  J*(eu)  can  be  used  in  place  of  the 
general  cost: 

f.(eu)=  min  C.(eu,p) 

P  €  bj 

that  was  introduced  in  the  previous  chapter  to  handle  upstream  requirements  uncertainty. 
Thus,  we  may  now  apply  the  approach  of  that  chapter  to  handle  both  upstream  and 
downstream  uncertainties  in  an  integrated  manner. 

4 .  Computational  Issues 

Computation  of  J*^)  involves  solving  the  optimization  problems  (1)  and  (3), 

which  requires  a  model  for  the  response  y  as  a  function  of  the  parameters  p  and  the 
downstream  uncertainty  Ed-  Moreover,  a  model  for  the  downstream  uncertainty  distribution 
is  also  needed.  Such  a  model  can  either  be  obtained  from  scientific  or  experimental 
knowledge.  If  the  dependency  of  y  and  Ttd  on  these  factors  can  be  specified  in  closed 
mathematical  form,  analytical  optimization  methods  can  be  applied  in  solving  (1)  and  (3). 
If,  however,  the  relationships  can  only  be  represented  in  some  symbolic  form  or  derived 
through  simulation,  then  problems  (1)  and  (3)  must  be  solved  using  some  sort  of  search 
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approach.  In  most  practical  cases,  one  needs  to  incorporate  specific  domain  knowledge  or 
some  structural  knowledge  about  the  problem  to  devise  an  efficient  search  method  to  solve 
(1)  and  (3).  This  is  where  artificial  intelligence  (AI)  technology,  in  particular  knowledge- 
based  technology,  may  be  extremely  useful. 

5.  Developing  the  Quality  Versus  LCC  Trade-Off  Curve 

Conceptually,  computing  the  trade-off  curve  in  Figure  IV-3  is  straightforward,  but 
practically,  it  may  be  a  difficult  or  even  analytically  intractable  problem.  Even  so,  the 
mathematical  formulation  provided  by  the  equations  given  in  the  preceding  section  can 
serve  as  a  guideline  in  developing  a  practical  solution  method  that  approximates  the 
mathematical  formulation.  One  approach  to  this  is  as  follows: 

Let  po  be  our  choice  of  design  parameters  after  solving  optimization  problem  (1). 
Problem  (1)  could  be  solved  using  a  variety  of  methods,  from  standard  mathematical 
optimization  techniques  to  experimental  design  methods,  such  as  those  recommended  by 
Taguchi  or  others.  Now  let  us  develop  an  estimated  LCC  using  design  p0  as  a  baseline. 

This  has  been  done  in  many  real  development  efforts  [Refs.  8,  9],  and  standard  templates 
(models)  exist  for  such  calculations.  Next  let  us  identify  all  of  the  exogenous  random 
variables  in  the  LCC  model  that  depend  on  po  or  on  specific  management  choices  (how  to 
manage  the  maintenance  process,  for  example).  Next  we  vary  the  design  parameters  from 
p0  and  examine  the  effect  of  these  variations  on  LCC  via  the  LCC  model.  With  certain 

assumptions  on  the  behavior  of  the  exogenous  variables,  the  effects  of  these  variations  on 
LCC  may  be  estimated.  If  we  then  find  the  direction  of  change  that  gives  the  greatest 
change  in  LCC,  we  have  identified  where  we  have  optimum  leverage  on  LCC  through 
design  parameter  variation.  We  next  examine  the  effect  of  such  a  change  on  quality  level. 
By  alternating  between  considerations  of  quality  and  LCC,  we  hope  to  arrive  at  a  new 
choice  of  design  parameters  that  gives  us  better  LCC  at  minimal  reduction  in  quality.  The 
search  procedure  described  above  can  be  implemented  as  a  local  search  method  in  seeking 
8*,  the  level  of  quality  at  which  our  dissatisfaction  J*(eu)  is  minimized. 
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C.  MANAGEMENT  OF  UNCERTAINTIES 


I .  Management  of  Upstream  Requirements  Uncertainties 

In  the  preceding  discussions,  the  requirements  specification  eu  has  been  regarded  as 
given.  Clearly,  we  can  also  regard  it  as  a  control  parameter  in  design,  as  done  by  Taguchi 
[Refs.  4,  5,  6];  however,  there  is  a  subtle  difference  between  eu  and  p:  the  choice  of  p  is 
made  after  eu—p  represents  design  parameters  chosen  by  the  designer  after  eu  is  specified. 
eu,  in  contrast,  is  chosen  after  realizing  what  can  be  achieved  in  fulfilling  certain  needs  in  a 
cost-effective  manner. 

Let  Q  represent  the  range  of  eu  that  the  upstream  members  consider  as  feasible 
requirements  that  can  be  achieved  in  fulfilling  certain  needs.  The  different  degrees  of 
likelihood  that  a  particular  Eu  will  become  the  final  requirements  specification  is  represented 
by  7t(£u)  defined  on  O.  7t(£u)  is  normalized  to  give 

J  Ttltg  d£u  =  1  (4) 

Q 

If  Q  is  a  discrete  set,  then  (4)  is  replaced  by 

£*(£?)  =  !  (4)' 

e^e  £1 

Note  that  7t(eu)  does  not  represent  an  objective  probability  distribution  for  eu,  but  rather 
represents  our  initial  assessment  of  how  likely  the  requirements  will  be  finally  frozen  to  eu. 

If  e£  t  Q  is  such  that  total  dissatisfaction  level  J*(£°)  is  large,  then  while  e£  is  a 
feasible  set  of  requirements  that  can  be  achieved  in  fulfilling  certain  needs,  the  performance 
and/or  cost  of  a  product  designed  using  such  these  requirements  as  guidelines  will  be 
unsatisfactory.  Let  Q.'  be  a  subset  of  Q  constructed  by  eliminating  all  e£  that  yield 

unsatisfactory  performance  or  cost. 

Now  there  are  three  types  of  situations  that  may  arise,  as  illustrated  in  Figure  IV-4. 
In  Situation  A,  we  have  the  good  fortune  in  that  what  we  anticipate  to  be  the  most  probable 
requirements  specification  leads  to  a  final  design  with  acceptable  dissatisfaction  level.  In 
situation  B,  there  is  some  compromise  between  requirements  and  dissatisfaction.  Situation 
C  occurs  when  there  is  conflict  between  upstream  requirements  and  downstream 
performance  or  cost  achievement.  In  situations  A  and  B,  the  new  range  of  possibilities  for 
eu  can  be  reduced  to  Q';  and  the  new  7t'(eu)  can  be  modified  by  adjusting  ji(eu)  to  fall 
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P  -  threshold  value  for  unsatisfactory  performance. 

Figure  IV-4.  Upstream-Downstream  Interactions 
within  the  range  Q'~ simple  adjustment  guidelines  could  be  that  if  o^(eu)  and  y*(eu)  are 
low,  then  adjust  7t(eu)  upward  and  vice  versa.  The  newly  adjusted  7i'(eu)  is  then 
normalized  within  the  range  Q'.  A  possible  change  from  7t(Eu)  to  7t'(£u)  is  illustrated  in 
Figure  IV- -5.  Management  judgment  is  necessary  in  requiring  such  a  modification,  which 
can  be  different  in  different  situations. 


Figure  IV-5.  Modifications  inrc'(eu)  for  Unconflicting  Situations 

The  case  of  conflict  indicates  the  situation  in  which  all  feasible  requirements 
specifications  £u  e  Q  will  lead  to  unsatisfactory  product  performance  and/or  cost.  An 
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effort  to  resolve  the  conflict  as  early  as  possible  is  crucial.  Otherwise,  the  continuation  of 
the  development  process  will  lead  to  an  extremely  unfavorable  outcome  that  will  be  very 
expensive  to  fix.  The  upstream  requirements  team  needs  to  reexamine  the  rationale  they 
used  in  arriving  at  Q  and  Jt(eu).  The  design  team  can  point  to  specific  requirements  that 
lead  to  the  unfavorable  outcome  or  explore  whether  certain  downstream  uncertainties  can  be 
reduced.  The  process  of  conflict  resolution  will  vary  for  different  situations.  However, 
identifying  the  need  for  such  a  process  to  take  place  in  the  early  product  development 
process  will  lead  to  improvements  in  total  product  development  lead  time. 

2.  Selection  of  Design  Concept 

In  this  section  we  consider  how  to  select  from  alternative  design  concepts, 
assuming  the  initial  requirements  uncertainty  is  represented  by  7t(eu)  as  in  Figure  IV-6.  As 
an  example,  suppose  that  three  different  basic  approaches  are  proposed  by  three  different 
designer  groups.  Each  group  has  gone  through  the  generalized  loss  function  computation 
of  Section  D.l  and  three  different  curves  .!*(£„)  have  been  obtained  as  illustrated  in  Figure 

IV-6.  Approach  1  will  always  result  in  a  satisfactory  outcome.  If  such  an  approach  is 
adopted,  then  we  can  just  let  the  uncertainty  in  eu  be  reduced  naturally.  If,  however,  the 
second  or  third  approach  is  to  be  taken,  the  requirements  team  must  determine  whether 
those  e„  that  provide  lower  J^eJ  (i  =  2  or  3)  can  actually  fulfill  the  needs.  In  fact.  Figure 

IV-6  provides  a  focus  on  the  range  of  eu  that  the  requirements  team  needs  to  explore.  The 
fact  that  the  third  approach  can  lead  to  substantially  improved  satisfaction  within  certain 
ranges  of  eu  stimulates  the  requirements  team  to  reexamine  its  original  assumption  in 
terminating  7t(eu)  at  lower  values.  A  new  assessment  may  indicate  that  the  requirements 
specification  can  be  reduced  to  the  region  surrounding  the  minimum  of  J*(eu),  leading  to 

selection  of  approach  3  as  best 

If  the  requirements  team  feels  that  7t(eu)  can  be  shifted  somewhat  to  the  right,  then 
approach  1  should  probably  be  eliminated  from  consideration,  because  the  specification  can 
probably  now  be  restricted  to  Q'  (with  7t(eu)  modified  appropriately),  and  with  such  a 
restriction  approach  2  now  gives  a  lower  dissatisfaction  level  than  approach  1. 

3 ,  Dynamic  Reduction  of  Requirements  Uncertainties 

Suppose  that  a  specific  design  approach  i  is  chosen.  The  management  of  the 
overlapping  product  development  process  must  then  determine  how  to  control  the  shape  of 


Figure  IV-6.  Comparison  of  Three  Basic  Design  Approaches 

the  funnel-managing  the  dynamic  reduction  in  requirements  specification  uncertainties  over 
time.  In  Sections  C.l  and  C.2,  we  described  how  the  original  uncertainty  [Q,  7t(eu)]  is 
refined  to  (X2',  7t'(eu)]  after  going  through  a  full  cycle  in  integrating  downstream  and 
upstream  analysis  in  a  nonconflicting  situation,  [fit,  7t(Eu)]  can  be  further  refined  if  we  can 

•  Obtain  better  knowledge  of  what  is  achievable  in  fulfilling  needs— expend 
resources  in  understanding  what  are  the  real  needs  and  what  is  achievable  via 
technology. 

•  Compute  J*(eu)  more  accurately.  In  the  preliminary  evaluation  of  downstream 
uncertainties,  for  example,  a  simple  model  may  have  been  used  in  order  to  get 
a  quick  first-cut  analysis.  Thus,  modeling  error  may  be  responsible  for 
undesirable  dissatisfaction  measurements  in  part  of  Q.  One  may  thus  expend 
resources  to  refine  certain  components  of  the  model  that  will  reduce  the 
downstream  uncertainties.  Other  ways  to  reduce  downstream  uncertainties 
include  modification  of  the  design  approach  (such  as  reducing  the  number  of 
components  or  using  standardized  parts).  These  activities  may  lead  to  a  more 
accurate  characterization  of  J*  over  the  region  Q,  giving  us  a  better  picture  of 
how  to  move  to  an  Q'  with  much  lower  dissatisfaction  levels. 

Determining  what  activities  should  be  carried  out  dynamically  over  time  to  reduce 
requirements  uncertainties  as  quickly  as  possible  is  the  key  management  control  issue. 
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Some  uncertainty  reductions  occur  passively  as  the  result  of  certain  exogenous  events; 
others  are  planned  by  management  control.  This  control  process  can  be  better  represented 
by  a  heuristic  rather  than  an  analytical  process,  although  some  analysis  may  be  useful  in 
supporting  the  heuristic  process. 

4 .  Flexible  Design 

In  the  beginning  of  the  design  phase  in  an  overlapping  process,  the  design  team 
must  be  designing  when  the  requirements  are  not  completely  specified.  Even  though  a 
basic  approach  may  have  been  selected,  the  team  will  want  to  build  flexibility  into  the  early 
design  decisions  so  that  when  the  requirements  are  refined  later,  the  design  space  will  not 
have  been  so  constrained  by  the  early  decisions  as  to  prevent  the  team  from  achieving  the 
final  specification.  One  way  to  do  this  is  as  follows: 

Consider  a  certain  design  approach  i.  Let  j=  1  ,...n  and 

S.  cS.  ,  j=l,...n  be  subsets  of  the  parameter  space  S.. 

i  M  1 

Thus,  within  the  approach  i,  we  can  have  a  subapproach  (ij)  which  is  characterized  by 
additional  constraints  that  are  placed  in  the  parameter  space  Sj.  The  restriction  S.  c  S. 

Vi 

implies  that  the  approach  (ij)  is  less  flexible  than  approach  (ij+i)  within  the  basic  approach 
i.  In  general,  increased  flexibility  will  mean  higher  design  cost.  Clearly, 

of  (ej  >  of  (£„):  more  flexibility  will  also  result  in  higher  quality.  The  effect  of 

j  >i 

flexibility  on  LCC  is  not  clear.  While  less  constraints  allow  more  freedom  in  finally 
choosing  a  design  with  a  low  LCC,  the  cost  for  flexibility  may  be  substantial.  Therefore,  a 
compromise  is  needed  to  determine  the  optimum  flexible  design  approach. 

We  can  add  a  step  increase  in  flexibility  by  having  parallel  design  teams  take  more 
than  one  basic  approach  and  within  each  basic  approach  determine  the  optimum  flexibility 
level.  Although  this  method  will  increase  the  design  cost  in  some  highly  uncertain 
situations,  parallel  design  teams  may  be  the  best  approach. 

The  determination  of  the  optimum  level  of  flexibility  depends  on  the  uncertainty 
levels.  Thus  as  the  requirement  uncertainties  are  reduced  over  time,  the  optimum  flexibility 
level  will  also  be  reduced.  As  the  requirements  are  fully  specified,  the  flexibility  level  will 
be  reduced  to  zero:  S;  -*  p(e£).  The  dynamic  aspect  of  how  the  optimum  flexibility  level 
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will  be  determined  is  not  worked  out  completely  here,  but  we  believe  it  can  be  developed 
by  further  extending  the  reasonings  as  put  forth  in  Sections  C.1-C.3. 

5 .  Staging  of  Development  Phases  in  Product  Development 

In  the  discussions  in  Sections  C.1-C.4,  we  have  assumed  that  the  design  phase  has 
one  upstream  phase  (requirements  specification)  and  one  downstream  phase.  In  practical 
situations,  more  than  one  phase  upstream  or  downstream  may  exist.  This  section  discusses 
the  case  where  two  upstream  phases  precede  design.  In  the  planning  of  an  overall  product 
development  process,  the  important  issues  to  be  considered  are  the  identification  and 
ordering  of  the  phases  involved.  In  an  overlapping  process,  phase  1  precedes  phase  2  if 
the  output  of  phase  1  is  frozen  before  that  of  phase  2. 

The  design  team  requires  two  different  types  of  specification.  The  first  type  is 
related  to  the  physical  requirements  that  the  product  is  supposed  to  have;  and  the  second 
type  is  related  to  new  technology  that  is  supposed  to  be  incorporated  in  the  product  If  new 
technology  is  to  be  incorporated  into  the  product  should  we  freeze  the  technology  features 
or  the  physical  requirements  first?  The  following  sections  describe  two  different  orderings, 
which  are  appropriate  under  different  situations. 

a.  Need-Driven  Process 

Consider  the  case  where  we  desire  to  integrate  a  set  of  new  technologies  in  a 
product  development.  These  new  technologies  are  proven  and  their  features  are  known, 
but  they  have  never  been  integrated  before  into  any  product  similar  to  the  one  we  are 
developing.  Therefore,  how  they  should  be  integrated  and  what  the  resulting  product 
capabilities  would  be  are  still  unknown.  Since  the  basic  features  of  these  technologies  are 
known,  we  may  be  able  to  bound  the  realm  of  capabilities  after  they  are  appropriately 
integrated.  Since  there  are  numerous  ways  to  integrate  these  technologies,  the  technology 
integration  process  can  be  facilitated  by  specifying  the  physical  requirements  first,  which 
will  provide  a  focus  for  integration.  Therefore,  in  this  situation,  we  should  freeze  the 
physical  requirements  before  freezing  the  technology  integration. 

Note  that  in  this  case,  the  physical  requirements  that  the  product  should  meet  are  the 
driving  force.  These  requirements  reflect  our  needs  for  the  product.  We  refer  to  this 
situation  as  a  need-driven  or  market-driven  process. 
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b.  Technology-Driven  Process 

While  the  design  team  is  designing  a  product,  an  R&D  team  may  be  developing  a 
new  technology  that  can  significantly  improve  certain  attributes  of  the  product.  For 
competitive  reasons  (either  in  a  defense  or  commercial  sense),  we  may  desire  to  incorporate 
such  technological  developments  into  the  product  design  as  early  as  possible.  While  the 
R&D  team  may  assure  management  that  the  new  technology  will  be  available  in  time  for 
incorporation  into  the  new  product,  such  an  estimate  is  usually  not  accurate  and  in  many 
cases  is  optimistic.  Moreover,  the  precise  features  that  can  be  successfully  achieved  with 
new  technology  may  not  be  known,  although  some  range  of  estimates  for  these  features 
can  be  provided  by  the  R&D  team. 

In  this  case,  no  meaningful  physical  requirements  can  be  frozen  prior  to  availability 
of  the  new  technology,  since  they  will  depend  on  whether  such  a  superior  technology  can 
be  made  available,  which  will  affect  our  desires  for  the  physical  requirements  of  the 
product  We  argue  that  in  this  case,  the  technology  features  should  be  frozen  before  the 
product's  physical  requirements. 

We  refer  to  this  as  a  technology-driven  process  since  the  successful  development  of 
the  new  technology  provides  a  focus  for  specifying  the  physical  requirements  which,  in 
turn,  drives  the  product  development  process. 

Note  that  both  processes  incorporate  technology  development  and  marketing 
(relating  needs  to  physical  requirements  specification)  in  the  product  development  process. 
The  distinction  is  which  activity  provides  the  focus  that  drives  the  product  development. 
The  technology-driven  process  is  more  risky  than  the  market-driven  process;  however,  the 
technology-driven  process  plays  a  key  role  in  fostering  worldwide  competitiveness  and  is 
responsible  for  most  innovative  products  developed  n  this  world.  For  complex  products, 
we  may  actually  use  a  mix  of  needs-driven  and  technology-driven  processes— certain  new 
technologies  will  be  well  tested  and  used  for  the  first  time  in  the  product  application,  while 
others  may  still  be  pending  completion  by  R&D  groups.  In  this  more  complex  situation, 
the  appropriate  staging  becomes  even  more  important  to  control  the  success  of  product 
development  We  will  generally  have  an  interlacing  of  partial  technology  and  requirement 
freezing  during  the  whole  specification  process  (see  Figures  TV -7  through  IV- 10). 


IV-17 


Figure  IV-7.  Market-Driven  Process 
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Figure  IV-10.  Complex  Mixed  Process 


D.  APPLICATIONS  TO  MANAGING  UPSTREAM  UNCERTAINTY 


1.  Concurrent  Engineering 

Recent  initiatives,  such  as  the  Defense  Advanced  Research  Projects  Agency 
(DARPA)  Initiative  in  Concurrent  Engineering  (DICE),  have  advocated  the  conversion  of  a 
sequential  product  development  process  into  one  in  which  the  technology  development, 
design,  and  manufacturing  engineering  activities  are  pursued  concurrently.  The  focus  has 
been  on  developing  a  parallel  information/computing  architecture  that  allows  synchronized 
evolution  of  these  activities  with  progressive  refinement  [Ref.  10].  However,  what  has  not 
been  addressed  is  the  issue  that  the  conversion  of  sequential  activities  into  parallel  activities 
creates  uncertainties  that  must  be  managed  properly  to  ensure  success.  This  section 
addresses  such  issues.  We  believe  these  issues  are  fundamental  to  any  concurrent 
engineering  effort 

Two  issues  of  major  importance  in  concurrent  engineering  are  staging  phases  and 
freezing  of  phase  decisions  through  dynamic  reduction  of  ambiguity  through  integration  of 
upstream  and  downstream  analyses.  When  technology  development  is  in  its  infancy,  any 
concurrent  effort  in  design  is  probably  too  costly.  Therefore,  the  issue  is  at  what  stage  of 
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technology  development  should  the  design  effort  start.  The  marketing  activity  that  focuses 
on  discovering  people's  needs  must  also  occur  at  the  same  time. 

Once  a  staging  decision  is  made,  the  inherent  overlapping  paradigm  introduces 
upstream  and  downstream  uncertainties  as  discussed  in  Section  C,  and  a  methodology  is 
needed  to  address  this  problem. 

We  believe  that  the  discussions  in  Sections  B-C  can  provide  a  proper  top-level 
framework  for  the  development  of  an  appropriate  information  management  system  that  can 
support  concurrent  engineering.  Of  course,  a  great  deal  of  research  is  needed  to  enable 
such  a  development  to  be  successful. 

2 .  Planning  of  a  Science  and  Technology  Program  in  Conjunction  with 
Advanced  System  Developments 

S&T  research  is  an  independent  activity  with  the  primary  objective  of  advancing  the 
frontier  of  knowledge,  which  will  lead  to  innovative  technological  development.  Such 
advancements  will  not  only  affect  specific  vertical  applications  but  also  provide  a  platform 
for  many  advanced  product  developments.  For  example,  basic  research  in  advanced 
materials  will  affect  the  aerospace,  automobile,  and  many  other  industries. 

The  basic  premise  of  concurrent  engineering  is  to  integrate  such  research  activity 
into  a  specific  advanced  product  development  process.  The  research  is  treated  as  an  earlier 
phase  in  the  product  development  process.  By  performing  one  cycle  of  downstream  and 
upstream  analysis,  one  can  determine  whether  the  status  of  basic  research  can  potentially 
provide  the  technology  to  ensure  the  success  of  the  perceived  advanced  product  (no 
conflicts  arise).  If  no  conflicts  arise,  then  one  can  apply  the  analysis  discussed  in  the 
preceding  paragraphs  to  evaluate  the  effect  of  the  basic  research  to  such  product 
development.  If  conflicts  do  arise,  studying  the  reasons  for  the  conflicts  should  lead  to 
modifications  to  our  advanced  product  development  program,  modifications  to  our  basic 
research  directions,  or  modifications  to  both. 

However,  basic  research  should  affect  a  class  of  products,  not  just  one.  For  each 
active  advanced  product  development  project,  the  analysis  described  in  the  preceding 
paragraph  could  be  applied.  For  each  planned  advanced  product  development  project,  a 
simplified  analysis  based  on  this  concept  can  be  used.  Finally,  to  access  the  value  of  a 
certain  mix  of  research  directions,  an  integration  of  the  assessment  of  effects  to  all  active 
and  planned  product  development  projects  would  be  necessary.  The  proper  integration  of 
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these  analyses  into  an  overall  strategic  planning  and  management  system  for  technology 
base  activities  is  a  potentially  fruitful  area  of  research  that  should  be  further  investigated. 

E.  APPLICATION  TO  MANAGEMENT  OF  DOWNSTREAM 
UNCERTAINTIES 


I .  Downstream  Uncertainties  and  Reliability  Specification 

Downstream  uncertainties  can  be,  to  some  extent,  influenced  by  design  choice; 
however,  such  uncertainties  are  not  completely  controllable  by  design  since  internal  and 
external  noises  usually  exist  that  will  influence  such  uncertainties.  This  example  considers 
the  implications  of  uncertainty  in  product  reliability  (R). 

Let  R°  be  the  planned  average  reliability  that  the  designers  seek  to  achieve.  This 
can  be  done,  for  example,  by  reducing  parts  count,  selecting  better  quality  parts,  and 
providing  better  heat  ventilation.  However,  the  reliability  actually  realized  in  the  field  will 
also  be  influenced  by  other  noises  represented  by  £d,  whose  distribution  is  influenced  by 
the  choice  of  certain  design  parameters  p.  In  functional  form,  we  have 


R°  =  R°(p)  ;  7t(edlp) 

(5) 

The  reliability  actually  realized  will  be 

R  =  R°  +  ed 

(6) 

The  total  LCC  for  the  product  is 

LCC  =  Cp  (R°(p))  +  CM  (R)  +  Cs  (R) 

(7) 

where 


Cp  (R°(p))  is  the  product  development  cost 

Cm(R)  is  the  total  life  cycle  scheduled  maintenance  cost 

Cs(R)  is  the  total  life  cycle  service  repair  costs. 


Let  p*(R*)  be  an  optimizing  solution  of 

rrjjn  {cp[R°(P)J  +  EjcM(R°(P)+ed)  +  CR(R°(P>+ed|  { R°(p)  =  R* 


(8) 


Now  we  can  rewrite  (7)  as 

LCC(R\ed)  =  Cp(R*)  +  CM(R*+e*)  +  Cr(R*+e*)  (9) 


IV-21 


i 


where  £d  has  distribution  n(e*  |p*(R*)).  Thus  the  specification  of  R*,  the  reliability  level, 

does  indirectly  influence  the  downstream  uncertainties. 

In  general,  we  will  have  the  curves  for  the  cost  components  as  given  by  Figure 
IV- 1 1,  where  R  =  R*  +  £d.  From  the  Cp(R*)  curve,  we  see  that 


dC?(R*) 

8R* 


>0 


axp(R*) 

p  >0 


9R 


*2 


(10) 


However,  from  the  Cm(R)  +  Cs(R)  curve,  we  see  that 

a(cM(R)  +  cs(R)}  _  32(cm(R)  +  cs<r))  ^ 

"in  O  ~ 


8R 


0 


9R 


(11) 


Now  if  we  take  the  expected  value  for  LCC  (R*,ed)  we  have 


LCC(R*)  =  J  LCC(R*,e*)  Jt(ed  *P*(R*))d£* 


(12) 


=  Cp(R*)  +  J  +  cs(R  +ed>}  w(ej  lp*(R+)ded 

From  (12)  we  see  that  LCC(R*)  would  have  a  general  shape  as  given  in  Figure  IV- 12.  The 
point  R*  is  the  optimum  reliability  level  to  be  specified.  If  R*  is  specified  as  greater  than 

R*,  then  the  marginal  cost  in  improving  reliability  is  higher  than  the  reduction  in 

maintenance  and  repair  cost 


Suppose  that  the  product  under  consideration  is  an  equipment  that  is  needed  for 
continuous  operation,  and  when  an  equipment  is  down  for  maintenance  or  repair,  a  spare 
one  is  needed  to  carry  on  the  operation.  Therefore,  we  may  have  an  added  availability 
requirement. 


If  we  require  that  N*  equipments  are  always  available,  then  we  must  have  more 
than  N  equipments  in  place  so  that,  on  the  average,  we  will  have  at  least  N*  equipments 
operational.  We  shall  refer  to  the  set  of  N  equipments  as  a  system.  Our  interest  in  this  case 
is  not  the  LCC  for  each  equipment,  but  the  LCC  for  the  total  system. 


Let  a  be  a  fraction  of  time  that  an  equipment  is  available  for  operation.  The 
availability  requirement  can  be  represented  by 


aN  >  N*  ;  N  =  total  number  of  equipments  in  the  system 


(13) 
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Figure  IV-11.  Cost  Components  of  LCC 


Figure  IV-12.  The  LCC  Curve 

a  is  dependent  on  R,  the  actual  reliability  realized.  If  the  first  equipment  issued  is  given  a 
planned  reliability  R*,  how  many  should  be  purchased?  This  can  be  computed  in  a  variety 
of  ways;  one  possible  approach  is 


where 


f  Y  ( o  ifct(R)N-N*>0 

[a  (R)  N  -  N  J  =  •{  ,  (15) 

a(R)  N-N  otherwise 

>» 

Regardless  of  the  specific  method  of  finding  N,  as  long  as  the  method  reflects  our  desire  of 
ensuring  (13),  we  have 

N  =  N(R*) 

with  the  property 

<  0  (16) 

9R 

Now  the  LCC  for  the  system  is  given  by 

LCCS  =  N  •  LCC  (17) 


where  LCC  is  the  individual  product  life  cycle  cost.  We  thus  have 

?E£s  =  isLLcc+Na^ 

9R  9R  3R 


Since  <  0,  at  the  point  Ri  where  ~  ®  ,  we  will  still  have 

dR  8R*  R*=Rj 


9LCCS 

dR*  R*=R, 


.  Thus,  general  shape  of  LCCs  as  compared  to  LCC  will  be  as  shown 


in  Figure  IV- 13.  R2  is  the  reliability  level  that  is  optimum  for  the  system.  R2  is  an 
increasing  function  in  N*  and  R2>Ri-  The  implication  of  this  result  is  as  follows— if  we  are 
considering  the  LCC  of  a  system  with  a  certain  system  operational  requirement,  then  it  pays 
to  develop  a  product  of  a  much  higher  reliability,  even  though  the  marginal  cost  in 
improving  the  reliability  is  higher  than  the  marginal  reduction  in  maintenance  and  repair 
cost  for  each  product  considered  individually. 


2 .  Uncertainty  in  Reliability  and  Parts  Availability 

Suppose  that  the  design  team  must  decide  whether  they  should  design  the  product 
based  on  standardized  parts  that  are  readily  available  or  design  the  product  by  specifying 
the  parts  needed  and  ask  certain  vendors  to  manufacture  those  parts.  If  the  second 
approach  is  used,  we  can  specify  the  reliability  level  for  the  parts  that  will  result  in  the 
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Figure  IV-13.  LCC  s  Curve  as  Compared  to  LCC  Curve 

optimum  product  reliability  level  as  discussed  in  the  preceding  section.  However,  with  the 
first  approach,  we  have  to  accept  whatever  reliability  level  is  offered  by  the  suppliers. 

In  the  first  case,  the  LCC  of  the  product  does  not  depend  on  availability  of  parts  but 
on  only  their  reliability  level.  However,  in  the  second  case,  where  there  is  an  availability 
constraint,  parts  availability  plays  an  important  role. 

Let  LCCi  be  the  average  life  cycle  cost  if  the  first  approach  is  used  and  LCC2  is  the 
average  life  cycle  cost  if  the  second  approach  is  used.  Let  a*  be  the  fraction  of  time  that  an 
equipment  is  available  for  operation  if  the  product  is  developed  using  the  ith  approach.  The 
constraint  is 

a.  N  >  N*  i  =  1,2  (19) 


The  fraction  aj  depends  on  Rj  and  ij,  where  Rj  is  the  parts  reliability  and  q  is  the  lead  time 
in  parts  availability  if  the  ith  approach  is  used.  We  have  the  property 


dx: 


dR 


l->  0 


9<Xj 

dT 


£  0 


(20) 


Using  the  similar  argument  as  in  the  last  section,  we  see  that  the  number  of  equipments 
purchased  N  will  have  the  following  properties: 


-^4  <  0  >0  (21) 

dR  dl- 

I  1 
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where  R*  is  the  planned  reliability  and  i*  is  the  planned  availability  of  parts  if  the  ith 
approach  is  taken. 

Suppose  LCCi  >  LCC2,  (XjCRj.O)  <  a^Rj.O):  i.e.,  if  lead  time  in  parts 
availability  is  zero,  then  option  2  is  better  than  option  1.  The  plots  for  LCCsj,  i=l,2, 
against  1  will  be  as  those  shown  in  Figure  IV-14.  If  7ti(i),  ^2(1)  are  as  given  in  Figure 
IV- 14,  then  for  the  system  LCC,  option  2  is  better.  If,  however,  7t2(t)  is  moved  more  to 
the  right,  option  1  is  better.  Since  Jti(t)  is  less  controllable  but  112(1)  is  more  controllable, 
the  issue  is  whether  we  can  have  effective  control  on  the  vendor  in  reducing  lead  time  in 
parts  delivery.  In  general,  if  a  component  has  special  features  that  are  unique  and  are 
absolutely  necessary,  then  standardized  parts  may  not  be  that  readily  available,  in  which 
case,  option  2  may  be  the  better  choice.  The  analysis  indicates  that,  in  this  case,  more 
emphasis  should  be  devoted  to  tightening  the  relationship  with  the  vendor  selected  to 
provide  the  component.  On  the  other  hand,  if  standardized  components  can  be  used,  then 
most  likely  iti(t)  will  be  clustered  at  low  values  of  1,  which  implies  that  option  1  may  be  a 
better  choice.  For  a  product  with  many  component  parts,  this  analysis  can  be  used  to 
determine  which  component  parts  should  be  obtained  from  standardized  markets  and  which 
parts  from  custom  or  semi-custom  markets.  Such  a  determination  will  provide  a  guideline 
for  product  design. 


Figure  IV-14.  System  Life  Cycle  Cost  as  a  Function  ofi 
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V.  DECISION  SUPPORT  SYSTEM  REQUIREMENTS 


A.  MANAGEMENT  STRUCTURE  TO  SUPPORT  OVERLAPPING 
PROCESS 

A  management  structure  that  is  appropriate  for  problem  solving  in  the  overlapping 
paradigm  is  illustrated  in  Figure  V-l.  Each  functional  group  is  responsible  for  problem 
solving  in  a  specific  phase.  The  functional  groups  may  be  formed  in  a  dynamic  manner— 
over  time,  members  in  group  i  may  change  and  the  mission  in  each  group  may  change  in 
response  to  exogenous  events.  The  manager  must  accomplish  the  following: 

•  Identify  phases  and  organize  functional  groups,  in  a  dynamic  manner,  in  line 
with  these  phases.  Team  stability  and  functional  optimality  must  be 
considered. 

•  Once  the  functional  groups  are  organized,  determine  the  starting  time  for  each 
phase  in  real  time  and  provide  guidelines  in  setting  the  degree  of  flexibility  at 
the  beginning  of  the  phase. 

•  Monitor  and  coordinate  consensus  seeking  among  functional  groups  to  manage 
the  reduction  of  flexibility  in  the  funnel  process  in  each  phase. 

Each  functional  group  has  similar  problem  solving  characteristics,  even  though  each 
group  uses  different  tools  and  methods  in  solving  its  assigned  problem.  The  common 
goals  are 

•  Focus  on  generating  appropriate  options  with  flexibility  when  ambiguity  is 
large.  Since  there  is  a  cost  incurred  in  generating  each  option,  the  team  must 
trade  off  this  cost  with  the  degree  of  flexibility. 

•  Focus  on  optimizing  the  product  when  ambiguity  has  been  reduced  to  a  level 
so  low  that  it  has  been  practically  eliminated. 

•  Frequently  communicate  with  team  members  in  the  upstream  and  downstream 
phases  while  work  is  in  progress.  Provide  review  of  decisions  about  to  be 
made  by  upstream  members  and  provide  suggestions  for  a  better  overall 
solution.  When  conflicts  arise,  exchange  points  of  view  to  achieve  consensus. 
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Figure  V-1.  Management  Structure  for  Overlapping  Paradigm 


While  both  the  manager  and  the  functional  groups  are  involved  in  the  consensus 
seeking  process,  their  roles  will  differ.  Whatever  consensus  among  different  groups  is 
reached,  it  is  important  that  all  of  the  functional  group  members  also  agree-consensus 
should  be  reached,  by  and  large,  among  the  functional  groups.  The  manager  should  guide 
the  consensus  seeking  process.  For  example,  the  manager  may  emphasize  a  sense  of  time 
urgency,  communicate  the  relative  trade-offs  among  the  three  process  attributes,  and 
suggest  new  ways  to  solve  conflicts. 


B .  DECISION  SUPPORT  SYSTEMS  FOR  UNCERTAINTY 
MANAGEMENT 

Many  of  the  current  research  activities  in  ULCE  are  driven  primarily  by  the 
technology  point  of  view-how  sophisticated  AI  and  distributed  processing  technology  can 
be  used  to  develop  a  complex,  distri  juted,  knowledge-based  system  that  helps  to  integrate 
design  and  manufacturing.  The  approaches  centers  on  the  notion  that  a  decision  in  the 
upstream  (design)  phase  may  severely  restrict  downstream  (manufacturing)  options. 
Therefore,  the  implications  of  upstream  decisionmaking  on  downstream  restrictions  should 
be  considered.  If  the  choice  imposes  too  many  restrictions  on  the  downstream  phase,  the 
upstream  team  member  should  be  alerted  or  the  upstream  team  should  be  prohibited  from 
making  such  a  choice.  The  technology  solution  advanced  to  achieve  this  is  to  develop  a 
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large  and  complex  knowledge-based  system  that  captures  all  of  the  relevant  downstream 
problem  solving  knowledge.  The  emphasis  is  on  "intelligent"  information  management 

While  this  technology  solution  seems  acceptable,  it  does  not  address  the  basic 
issues  that  any  product  development  process  faces— management  of  risks  and  uncertainties. 
Competitive  pressure  imposes  a  greater  demand  on  us  to  deal  with  these  issues  more 
effectively.  We  believe  that  an  overlapping  development  approach  in  which  risk  is 
effectively  managed  offers  the  most  promising  appoach  to  ULCE  implementation. 

The  overlapping  approach  has  been  adopted  in  many  design  activities.  However, 
the  overlapping  approach  will  introduce  upstream  and  downstream  uncertainties  (as 
discussed  in  Chapter  II),  which  implies  that  an  appropriate  solution  for  dealing  with  an 
overlapping  process  must  deal  with  such  uncertainties  directly.  Unfortunately,  most  of  the 
current  methods  adopted  for  the  overlapping  approach  in  design  are  primarily  deterministic 
methods  [Ref.  1  and  Ref.  12].  At  best,  only  downstream  uncertainties  are  considered 
[Ref.  4].  Thus,  decision  support  systems  that  support  conventional  solution  methods  in 
solving  problems  in  the  overlapping  approach  may  only  help  us  to  derive  an  unfavorable 
solution  faster. 

An  appropriate  computer  environment  that  supports  ULCE  must  support  the 
appropriate  risk  management  process.  We  shall  refer  to  such  a  computer  system  as  a 
ULCE  environment  A  ULCE  environment  must  be  compatible  with  a  management 
structure  that  is  appropriate  for  problem  solving  in  the  overlapping  paradigm.  Under  this 
paradigm  there  are  different  functional  groups,  each  responsible  for  problem  solving  in  a 
specific  phase.  These  functional  groups  are  formed  in  a  dynamic  manner.  Over  time, 
members  in  a  group  may  change  and  the  mission  in  each  group  may  change  in  response  to 
exogenous  events.  The  manager  must  identify  different  phases,  organize  functional  groups 
in  a  dynamic  manner  in  line  with  these  phases,  and  determine  the  ordering  and  the  starting 
time  of  each  phase.  We  shall  refer  to  these  as  management  control  activities.  Such 
activities  initiate  a  subprocess  to  be  carried  out  by  a  certain  functional  group.  The 
determination  of  such  control  activities  is  not  based  on  rigorous  analysis  but  rather  on 
creativity,  heuristics,  and  experience.  For  example,  the  discussions  in  Chapter  IV  deal 
with  the  evolving  phases  based  on  heuristic  arguments. 

Once  a  functional  group  begins  its  activities,  the  members  must  generate  flexible 
options.  The  appropriate  choices  among  these  options  are  made  by  integrating  upstream 
and  downstream  risk  analysis.  While  the  generation  of  options  is  based  on  the  members’ 

V-3 


( 


creativity,  heuristics,  and  experience,  the  risk  analysis  discussions  in  Chapter  IV  can 
provide  an  analytical  base  for  the  choice  of  options.  The  manager  handles  the  risk  by 
monitoring  and  coordinating  consensus  seeking  among  functional  groups  to  control  the 
reduction  of  flexibility  in  the  funnel  process  in  each  phase.  Chapter  IV  provides 
foundations  for  such  control  activities.  Note  that  creativity,  heuristics,  knowledge, 
experience,  and  mathematical  analysis  are  used  to  support  such  control  actions. 

Communication  among  all  team  members  in  the  upstream  and  downstream  phases 
is  crucial  so  that  downstream  analysis  can  help  provide  better  upstream  decisions. 
Moreover,  good  communications  allow  the  team  members  to  bring  out  potential  conflicts 
and  try  to  resolve  them  as  soon  as  possible.  Because  communication  among  team  members 
is  essential,  an  appropriate  networking  hardware  architecture  will  be  required-even  the 
digital  transmission  of  output  from  one  team  to  another  team  will  increase  overall 
productivity.  To  support  the  team  problem  process  in  product  development,  we  propose  a 
networking  of  workstations  as  illustrated  in  Figure  V-2. 

The  manager  workstation  supports  the  three  basic  activities— monitoring 
development  status,  management  control  and  coordination,  and  performing  analysis  to 
justify  decisions.  How  these  activities  are  carried  out  depends  on  the  manager's  working 
style. 

Monitoring  continuous  activities  is  not  merely  reviewing  all  the  updated  status 
information;  monitoring  implies  a  continuous  assessment  of  the  development  status-what 
options  have  been  generated  by  each  team,  when  convergence  has  started  to  take  place  in 
each  phase  and  how  fast  is  it  occurring,  how  each  team  is  progressing  according  to  the 
plan,  and  whether  conflict  has  arisen.  Monitoring  will  require  transformation  of 
accumulated  data  into  certain  indicator  variables  that  can  represent  the  development  status. 
The  data  can  be  in  symbolic  as  well  as  numeric  form,  as  can  the  indicator  variables.  The 
transformation  can  be  by  symbolic  manipulation  or  by  a  mathematical  model. 

The  values  of  the  indicator  variables  will  trigger  proper  management  control  and 
coordination  activities.  The  triggering  mechanism  can  be  based  on  rule-based  reasoning  for 
frequently  recurring  situations.  For  exceptional  situations,  the  manager  must  be  involved 
in  determining  the  control  action,  which  may  require  some  analysis.  What  analysis  should 
be  performed  and  how  it  should  be  performed  are  the  basic  issues  in  these  situations.  To 
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Figure  V-2.  ULCE  Environment 


support  such  activities,  a  model,  construction,  and  editing  environment  to  support  the 
analysis,  problem  formulation  activities,  and  reconfigurability  of  the  tools  in  the  tool-set 
tailored  to  the  specific  analysis  requirements  will  be  needed. 


An  individual  functional  group's  activity  in  arriving  at  a  certain  decision  is  triggered 
by  management  control  instruction.  In  beginning  a  decision  process,  group  members  will 
search  for  options  or  alternatives  based  on  what  is  instructed  and  what  is  known.  Such  a 
process  can  be  based  on  a  rule-based  reasoning  for  common,  recurring  situations  or  based 
on  the  members'  creativity.  Once  an  option  is  generated,  it  is  then  evaluated.  This  triggers 
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an  analysis  based  on  upstream-downstream  integration  as  discussed  in  the  previous 
chapter.  Such  an  analysis  requires  the  members  to  construct  an  analysis  model  and  pick  an 
appropriate  analytical  tool  to  solve  the  analysis.  The  analytical  tools  will  likely  be  based  on 
CAD/CAM,  statistical,  optimization,  simulation,  and  search  methods.  Therefore,  to 
support  the  group  members,  the  group  workstation  must  also  have  a  model,  construction, 
and  editing  environment  and  reconfigurability  of  a  subset  of  analytical  tools  (CAD/CAM, 
statistical,  simulation,  optimization,  etc.)  tailored  to  the  specific  model  formulated.  Note 
that  most  of  the  proposed  systems  that  support  ULCE  are  designed  to  facilitate  the 
downstream  integration.  To  integrate  this  with  upstream  analysis,  an  analysis  process,  as 
discussed  in  the  last  chapter,  must  be  incorporated. 

The  output  of  each  group's  decisions  goes  to  the  functional  group  for  the  next 
phase  as  well  as  to  the  global  data  base,  which  is  monitored  by  the  monitor.  The  decision 
being  made  in  each  phase  is  dynamically  changing.  For  example,  for  the  designer  group, 
the  decision  at  any  time  can  relate  to  the  set  of  design  options  being  considered,  the  degree 
of  flexibility  in  the  design  process,  etc. 

A  coarse  global  knowledge  base  should  be  used  to  capture  the  most  common 
knowledge-  relevant  to  the  development  process.  Such  a  knowledge  base  should  be  simple 
and  can  be  used  in  coming  up  with  first-order  analysis  and  recommendations.  A  more 
detailed  domain  knowledge  base  is  captured  in  individual  local  knowledge  bases  embedded 
in  each  functional  group's  workstation.  Each  local  knowledge  base  will  be  different  and 
can  only  capture  the  most  relevant  knowledge  for  the  specific  group's  activities.  Additional 
knowledge  (usually  new  knowledge)  will  be  provided  by  group  members. 

Because  of  rapid  advancements  in  technological  innovation,  the  life  cycle  of 
knowledge  will  be  short.  Thus,  the  knowledge  base  must  be  constantly  updated  or 
modified  to  represent  the  latest  knowledge  of  the  situation.  Therefore,  easy  rule  editing  and 
rule  main'  lance  capabilities  are  absolutely  necessary  for  knowledge-based  technology  to 
be  useful  in  high  technology  product  development  processes. 
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VI.  SUMMARY  AND  RECOMMENDATIONS 


A.  SUMMARY 

This  paper  describes  a  framework  that  addresses  the  risk  management  issue  in  the 
new  product  development  process.  An  overlapping  paradigm  for  the  development  process 
is  proposed,  which  creates  a  new  risk  management  problem.  This  new  problem  is  dealing 
with  upstream  and  downstream  uncertainties,  and  the  required  management  process  is 
coordinating  upstream  and  downstream  analysis  to  control  the  reduction  of  upstream 
uncertainty  so  as  to  converge  to  a  point  design.  A  method  for  integrating  the  upstream  and 
downstream  analysis  has  been  developed  based  on  development  of  a  generalized  loss 
function  to  deal  with  downstream  uncertainty  and  then  using  the  downstream  results  in  a 
subsequent  upstream  analysis. 

An  analytic  framework  for  consideration  of  issues  such  as  staging  of  the  various 
phases  of  a  development  project  was  also  developed  and  discussed  in  the  context  of 
problems  such  as  concurrent  engineering  and  science  and  technology  program  planning  and 
management 

Finally,  we  described  a  ULCE  environment  to  support  a  high  technology  product 
development  process.  The  main  focus  is  on  the  architecture  of  such  an  environment  and 
the  functional  capabilities  that  such  an  environment  should  have,  and  not  on  the  detailed 
hardware-software  system  specifications  and  designs. 

It  should  be  emphasized  that  the  research  reported  here  is  focused  on  providing  a 
foundation  that  allows  us  to  address  ULCE  properly  from  a  risk  management  perspective. 
Given  increasing  competitive  pressures,  it  is  becoming  more  important  that  we  learn  how  to 
develop  products  using  the  most  recent  technology  in  a  timely  manner  to  meet  user  needs, 
while  keeping  life  cycle  cost  low.  This  demands  far  more  attention  to  risk  management 
throughout  the  process.  Unfortunately,  this  issue  has  been  rarely  addressed  in  the  vast 
array  of  research  activities  focused  on  product  design  and  manufacturing. 


( 


Our  contribution  is  a  broad  treatment  of  such  issues  and  development  of  a 
foundation  for  further  research  activities.  For  example,  the  discussion  of  the  generalized 
loss  function  approach  to  managing  downstream  uncertainties  provides  a  solution  method 
at  a  conceptual  level  only.  To  implement  the  method,  we  need  to  describe  how  to  develop 
the  response  model,  the  model  for  the  downstream  uncertainties,  and  the  optimization 
methods  that  will  be  required.  In  practice,  the  construction  of  such  models  is  the  major 
difficulty.  In  many  cases,  analytical  form  for  such  models  may  not  be  obtainable,  which 
prohibits  straightforward  application  of  standard  optimization  methods. 

The  second  difficulty  is  the  assessment  of  uncertainties  in  deriving  the  loss 
function.  Such  assessment  may  be  done  by  extracting  experts’  opinions  in  common 
situations  or  using  a  Monte  Carlo  simulation  method.  Different  types  of  difficulties  are 
associated  with  these  two  approaches— the  first  approach  requires  converting  expert 
knowledge  into  an  appropriate  distribution;  the  second  problem  requires  choosing  the  right 
level  of  model  aggregation  with  an  appropriate  model  error  representation. 

B .  RECOMMENDATIONS  FOR  FURTHER  RESEARCH  AND 
DEVELOPMENT 

1 .  Evaluation  of  the  Generalized  Loss  Function 

In  this  research,  we  have  developed  the  concept  of  the  generalized  loss  function, 
which  balances  life  cycle  cost  with  quality  lost  due  to  deviation  achievement  of  physical 
requirements  (J*(eu)  as  derived  in  Chapter  IV).  Such  a  function  plays  a  major  role  in  the 
entire  risk  management  process.  Thus  the  success  or  failure  of  implementing  the  method 
discussed  in  this  paper  hinges  on  being  able  to  derive  or  approximate  J*(eu). 

The  evaluation  of  J*(£u)  requires  two  optimization  problems  (equations  (2)  and  (3) 
in  Chapter  IV).  The  difficulties  of  solving  these  optimization  problems  are  discussed  in  the 
preceding  section.  Research  on  a  methodology  to  solve  these  optimization  problems, 
which  in  many  situations  cannot  be  represented  in  analytical  form,  is  urgently  needed. 

Taguchi  suggested  certain  statistical  methods  [Refs.  6, 7]  using  experimental  design 
in  solving  one  of  the  two  optimization  problems  (equation  2).  However,  the  method 
proposed  by  Taguchi  may  be  computationally  prohibitive  when  dealing  with  a  complex 
design  problem  where  there  are  many  design  parameters  to  be  selected.  Orthogonal  array 
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experimentation  methods  [Ref.  7]  do  not  use  experts'  knowledge,  and  for  complex  design 
problems,  a  more  intelligent  method  of  pursuing  experiments  may  be  needed. 

We  feel  that  an  approach  that  extends  the  current  Taguchi  method  to  deal  with  the 
two  optimization  problems  presented  here  while  integrating  some  expert  systems 
technology  may  provide  a  practical  method  in  evaluation  of  J*(eu). 

2 .  Assessment  of  Requirements  Ambiguity  Based  on  Perceived  Need 

The  next  critical  function  that  is  needed  to  perform  risk  management  is  the 
requirements  specification  ambiguity  7t(eu).  This  function  is  assessed  in  the  beginning  of 
the  design  process  based  on  some  unclear  notions  of  how  the  product  should  be  used. 
Note  that  this  is  not  a  statistical  uncertainty  but  rather  a  reflection  of  the  limits  of  our 
knowledge  of  how  meeting  certain  design  requirements  will  lead  to  a  product  that  meets  the 
user's  needs.  Syed  and  Tse  [Ref.  13]  have  developed  an  approach  in  which  expert's 
knowledge  and  market  data  are  integrated  via  a  pairwise  comparison  method  to  relate  how 
certain  product  attributes  can  meet  the  needs  of  certain  market  segments.  While  the  exact 
method  may  not  be  transferable,  some  of  the  basic  concepts  employed  by  Syed  and  Tse  can 
be  applied  to  this  situation. 

3.  Design  Concept  Evaluation— Integrating  Requirements  Ambiguity  and 
the  Generalized  Loss  Function  Approach  for  Downstream  Uncertainty 

Integrating  requirements  ambiguity  and  the  generalized  loss  function  approach  is 
conceptually  rather  straightforward  (as  described  in  Chapter  IV);  however,  practical 
implementation  is  difficult.  Note  that  the  integration  hinges  on  generating  the  two  functions 
7t(eu)  and  J*(eu),  for  eu  e  Q.  With  Q.  a  continuous  parameter  set,  the  generation  of  these 
two  functions  for  all  parameters  will  be  totally  impractical.  We  need  a  methodology  to 
allow  us  to  approximately  evaluate  the  design  concept  as  discussed  in  Chapter  IV  without 
requiring  evaluation  of  J*(eu)  and  7t(eu)  for  all  eu  e  £L 

4.  Managing  the  Dynamic  Reduction  of  Upstream  Ambiguity 

One  cycle  of  the  downstream  and  upstream  integration  results  in  either  a  reduction 
of  requirements  ambiguity  or  identification  of  a  potential  conflict  situation.  Management 
must  determine  how  to  further  reduce  the  requirements  ambiguity  in  the  first  situation  and 
how  to  resolve  conflict  when  the  second  situation  arises.  The  solution  for  both 


management  issues  hinges  on  exploring  the  effective  use  of  resources  to  carry  out  certain 
activities  that  will  modify  or  refine  the  assessments  on  7t(eu)  and  J*(eu).  For  example,  a 
better  understanding  of  the  needs  and  how  they  can  be  satisfied  will  narrow  7t(eu)  and/or 
shift  Jt(eu).  Such  understanding  can  also  lead  to  modification  of  the  requirements  space 
(new  attributes  introduced  or  some  attribute  made  irrelevant). 

Ways  to  modify  or  refine  J*(£u)  can  include 

•  Refining  certain  parts  of  the  system  modeling 

•  Choosing  different  components 

•  Building  a  better  vendor  relationship 

•  Adopting  a  different  maintenance  strategy. 

Note  that  in  influencing  J*(eu),  we  may  have  to  engage  in  new  activities  now  (such  as  more 
accurate  modeling)  or  plan  to  engage  in  future  activities  (such  as  change  maintenance 
strategy). 

The  manager  thus  faces  a  host  of  options  from  which  to  tnoose  to  continue  the 
reduction  of  requirements  uncertainties  in  some  optimum  manner  or  try  to  resolve  potential 
conflicts.  Each  of  these  activities  requires  resources  in  terms  of  dollars,  man-hours,  and 
time.  Thus  the  problem  is  one  of  resource  allocation  so  that 

•  The  project  can  be  finished  according  to  schedule, 

•  The  development  cost  is  within  budget,  and 

•  The  available  resources  are  optimally  used. 

This  resource  allocation  problem  is  non-standard  since  all  possible  options  are  not  specified 
a  priori.  Rather,  the  generation  of  new  options  may  result  from  an  assessment  of  the 
solution  of  an  old  resource  allocation  problem  and  exploring  how  combinations  of  certain 
activities  will  influence  J*(£u)  and  n(eu). 

While  the  option  generation  process  is  based  on  heuristics  and  past  experience, 
evaluation  of  the  resource  allocation  process  should  be  based  on  cost-benefit  analysis.  The 
top-level  management  process  is  based  on  a  sequence  of  option/evaluation  subprocesses. 
We  believe  that  an  integration  of  AI  and  operations  research  will  facilitate  an  appropriate 
solution  to  this  problem. 
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5 .  Demonstration  of  Applicability  of  the  Methodology  to  Specific  Classes 
of  Problems  via  Real  Cases 

Since  the  development  process  and  the  proposed  method  are  different  from  the 
conventional  practice,  before  one  can  develop  some  of  the  heuristics  discussed  in  this 
section,  one  needs  to  accumulate  working  experiences  by  applying  the  methodology  to 
specific  classes  of  product  development  problems.  Another  objective  of  such  application  is 
to  demonstrate  the  usefulness  of  the  methodology.  We  propose  to  select  real  application 
cases,  which  by  themselves  are  topics  of  significant  importance. 

Some  of  these  application  problems  include  managing  the  contracting  process, 
product  identification  and  development,  concurrent  engineering  in  high  technology  product 
development,  and  planning  of  an  S&T  program  in  conjunction  with  advanced  weapons 
development 

6.  ULCE  Decision  Support  Environment 

To  support  the  implementation  process,  we  need  to  develop  a  ULCE  environment 
that  can  support  the  manager  in  controlling  dynamic  reduction  in  the  requirements 
ambiguity  and  the  functional  groups  in  integrating  the  downstream  and  upstream  analysis 
process  when  a  specific  ambiguity  level  is  provided  by  the  manager.  Individual  decision 
support  systems  are  currently  being  developed  for  supporting  certain  specific  functional 
group  activities  (for  example,  CAD/CAM).  Ignoring  all  of  the  existing  systems  and 
redeveloping  a  new  unified  ULCE  environment  from  scrap  is  impractical.  Therefore, 
research  on  how  to  integrate  and  evolve  the  current  systems  to  the  target  ULCE 
environment  is  the  major  challenge.  We  believe  that  this  requires,  first,  a  thorough 
understanding  of  the  workings  of  the  overlapping  process  as  well  as  how  the  management 
issues  arising  from  such  processes  can  be  addressed  and  solved  effectively  before  the 
proper  ULCE  decision  support  environment  can  be  designed. 
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